ECMAScript for XML - Direct XML Syntax in ECMAScript

[codeulike]

I've been using XML here and there for about 20 years now. It does have its uses. But I still don't have any idea what all that xmlns stuff is about, especially all the variations of it that involve colons. Like I know its something to do with namespaces or whatever. But to this day I open an XML file and in the first few lines there's a few xmlns pointing to some random complicated old urls and it just has this air of 'ignorable old overspecified thing because someone got too excited twenty years ago'

(except sometimes its not ignorable and then things get messy)

edit: yes I know what namespaces are for, and some of the simple uses are simple, but to try and understand xml namespaces and schemas in full is really complicated. 95% of the time this stuff just seems like fussy cruft.

[dwaite]

> But I still don't have any idea what all that xmlns stuff is about

Basically, they that by "extensible" they both wanted to support custom document markup languages/structures, but also the ability to extend those documents without needing to coordinate naming, etc.

But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself. They also made 1-2 important errors in the definition of that add-on.

This led to XML tools being modal, having to support an interpretation of a document treating "xmlns" as a regular attribute and one where it was a namespace that influenced the interpretation of all the attributes/elements.

This push of complexity onto the people building schemas and using tools grew as there were two camps - one which wanted XML to be about generic tools that work on all XML data (similar to JSON today) and one where you used XML to define a specific document format for consumption by format-specific tools.

Various specifications were led by the generic tooling camp or document centric camp. As a result, XML eventually wound up being a poor fit for both.

[saurik]

Namespaces allow you to mix and match document markup formats without conflicts, and without just praying that no one else happened to use the same prefix as you did.

[AlbertoGP]

The mistake with the namespace syntax is that they wanted to allow plain textual copy-and-paste to work, thus the different ways and places in the document where namespaces can be declared.

The big thing we missed was better tools from the get-go, specially xml-aware text editors. That’s why the editors of the XML specification wanted to make things a bit easier for people doing things like writing XML with a plain text editor, or line-oriented processing using Perl. I think the amount of grief we are stuck with because of those time-limited needs is not worth it, thus the word “mistake” in the beginning of this post.

In hindsight, if anyone asked me how to add namespace support for XML, I would have required them all to be declared at the root of the document, in the XML declaration:

    <?xml version="1.0" standalone="yes"
          xmlns="https://docbook.org/ns/docbook"
          xmlns:m="http://fake-w3.org/2001/Math/not-the-real-MathML"?>
    <book>
        ...
        <equation>
            <title>MathML example</title>
            <m:math mode="display">
                <m:row>
                    <m:underover>
                        <m:o>∑</m:o>
                        <m:row>
                            <m:i>x</m:i>
                            <m:o>=</m:o>
                            <m:i>a</m:i>
                        </m:row>
                        <m:row>
                            <m:i>b</m:i>
                        </m:row>
                    </m:underover>
                    <m:sqrt>
                        <m:i>x</m:i>
                    </m:sqrt>
                </m:row>
            </m:math>
        </equation>
    </book>

Additionally, I would require them to be unique: only one prefix per namespace. That would eliminate a lot of issues when writing XML processors, including editors.

I guess someone else mentioned this or a very similar idea at the time, and it was discarded to support plain text copy-and-paste by having the xmlns attribute in the element being copy-and-pasted. I don’t claim I would have done a better job, but I wish for a new version of XML that learns from these two and a half decades of use.

[AndrewDucker]

If you're using Schemas for your XML then you need namespaces in case you've got two different elements from different schemas that have the same name.

(We use schemas for all of our XML, because that way we can generate strongly-typed objects from them.)

[oreille]

Well it might look old, but it actually solved the whole JSON schema declaration and validation problem before JSON even existed - and it's embed into the standard.

[trzeci]

ActionScript 3.0 was a great example of implementing E4X.

I miss that language a lot. It has quite a few great concepts: XML, intuitive implementation of objects, where key can be anything. Statically typed. Prototypes. Typed vectors. for..each loop. Dictionary with weak keys (oh that I loved so much, it was so powerful to implement better memory management on top of this).

I spent like 10 years developing in it, now it's my 6 year since I've touched it last time : (

[ludamad]

I did a Masters on gradual typing for JavaScript/TypeScript. I definitely felt that a great practical implementation was lost in AS3. It made me first appreciate that dynamic typing is a godsend in truly dynamic cases, but otherwise types were my friend

[bokchoi]

Hey, I worked on the specification for this as a fresh out of school test engineer! Ah, the memories. It didn't take over the world, and in hindsight it should have worked a little differently, but I still think it's pretty neat. I haven't used it in a few years now but it is really easy to transform or extract data from an xml doc using Rhino and E4X.

[jchw]

Good ol’ E4X. It actually worked in Firefox, but I only ever used it in ActionScript. It was a little strange, but quite useful in some regards. There’s a bit more than just literals going on there.

[Aldipower]

I've used E4X a lot in heavyweight AS3 applications. It was nice and readable to work with. Built a complete offline museum with it, containing more then 160 interactive media stations you could walk through. This is 10 years ago. TBH not sure, how I would build the museum today. There seems a lack of technology for this niche nowadays.

[naranha]

Interesting how the embedded XML syntax resembles today's JSX, I wonder if it took inspiration from it.

[Marazan]

For me the fore-bearer of JSX is Flex's MXML.

[reaktivo]

It's listed as Prior Art on JSX's Github

https://facebook.github.io/jsx/#prior-art

[slver]

They're both XML-like. But they serve completely different purpose and have different semantics.

E4X produces a standalone (pure markup) mutable XML node tree intended to encode data for cross-platform communication and data exchange.

JSX produces an non-standalone (links to JS symbols, functions, etc.) node tree intended to encode DOM fragments for UI updates.

E4X is not needed today, because we use JSON for data exchange. So E4X is now simply... JS objects.

[flakiness]

Martin Odersky once mentioned that he added XML literal to Scala because it was 2000s (citation needed). Although it's hard to refrain from ridiculing these, it's probably not fair to do it. 2000s had its own collective craziness and this was one of them. We'll have such ones for 2020s but we can only spot it years later.

(Don't name it to show your smartness. Pointing a few is not hard, but pinpointing all is not possible unless you're a pure naysayer.)

[jchw]

Some things were bad ideas but we never really figured out why they were actually bad. It’s easy to incredulously state “of course it’s bad because X” but it takes some deep analysis to really get closer to the core of things. Sometimes the results are not what you would’ve expected at all. Sometimes it feels obvious in retrospect.

And then some ideas are actually great, but the execution of the idea was poor. This can really make it seem like the idea itself is bad or impractical even though it’s not.

Personally, I liked E4X. Its probably better off gone, but I think the idea wasn’t so awful. It sounds bad in retrospect, but I used it and it was far from the worst way to interact with XML.

[MaxBarraclough]

I'm out of the loop on this one - does Odersky regret it because JSON has largely supplanted XML, or does he regret it because it's not the sort of problem that is best solved with a language feature?

[paulirwin]

Another example of language support for XML is VB.NET. I loved this feature when I last used it (over 10 years ago), especially the LINQ syntax for generating tags.

https://docs.microsoft.com/en-us/dotnet/visual-basic/program...

[benibela]

I liked this syntax so much I now use XQuery for everything

[jansommer]

I would really like to use JSONiq as well, XQuery for JSON. It's such a beautiful language. Eagerly following along the development of RumbleDB and hoping to extract JSONiq from that one day (there's also support for XQuery)

[Marazan]

I loved E4X in Actionscript.

[olliej]

Fun fact: e4x is part of why JS has for(of) instead of something more sensible

[WorldMaker]

Huh? The current behavior of for(in) dates all the way back to the original JS standards (ES1). ES2015 had to use "of" to avoid breaking compatibility with existing ES1 for(in) usage. (Being able to replace/reuse for(in) would have kept JS more in line with Python which is also for/in.) It seems fairly sensible in comparison to some of the other proposed options.

Unless you were hoping for an entirely new keyword such as foreach (like C#'s foreach(in)), and in that case yes they couldn't do that because ES3 settled on a Reserved Keyword list and they didn't want to break ES3 compatibility either. While ES3 attempted forward compatibility by including some keywords related to E4X (and ES4's type system), the list of keywords they came up with in ES3 wasn't "because" of E4X. (It was because of "strict mode" and defining what "strict" meant as rather, er, strictly as possible.)