ECMAScript for XML - Direct XML Syntax in ECMAScript(en.wikipedia.org)
en.wikipedia.org
ECMAScript for XML - Direct XML Syntax in ECMAScript
https://en.wikipedia.org/wiki/ECMAScript_for_XML
43 comments
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.)
(We use schemas for all of our XML, because that way we can generate strongly-typed objects from them.)
>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.
Isn't that where the problems start, I'm willing to bet 99% of XML documents don't have more than one schema. We have ended up with a ton of complexity to support a minority of use cases. It's no wonder people embraced JSON.
Isn't that where the problems start, I'm willing to bet 99% of XML documents don't have more than one schema. We have ended up with a ton of complexity to support a minority of use cases. It's no wonder people embraced JSON.
yes exactly, they tried to make xml V1 cover every eventuality for all time and created a fussy mess
So many schemas are all or nearly all optional elements, so the point about typing rarely works oh in practice.
These days I wouldn't be surprised if fairly large portion of XML documents that are still in use/produced did have multiple schemas. Most of the simple use cases have already moved to JSON or similar formats.
One very common case where there are multiple schemas is SAML. SAML protocol responses have their own schema, SAML assertions have their own schema, assertions usually define their type with different schema (XML schema instance) & XML signatures have their own schema. https://www.samltool.com/generic_sso_res.php for example
One very common case where there are multiple schemas is SAML. SAML protocol responses have their own schema, SAML assertions have their own schema, assertions usually define their type with different schema (XML schema instance) & XML signatures have their own schema. https://www.samltool.com/generic_sso_res.php for example
Even worse than that: 99% of all schemas mandate exclusivity (or at least exclusive subtrees, it's been a while). The dominant schema techniques rule out markup unless you explicitly bends over for it while jumping through hoops.
Yes I know its got a use and it makes sense when stated simply but when you get into the details everything about XML is so excessive because they tried to cover everything, so then you have namespaces and default namespaces and target namespaces and because the schemas are also defined in XML you get DTDs and XSDs and you end up trying to describe arbitrary contraints using really fiddly tags.
The way JSON just kindof waltzed along and took over, despite the obvious drawbacks of it being schema-less, is really interesting.
The way JSON just kindof waltzed along and took over, despite the obvious drawbacks of it being schema-less, is really interesting.
I would argue the file format had nothing to do with JSON being popular: it is much much easier to generate and access an object that is essentially a native serialization format, so even if you never ever see the XML (and thereby never have to deal with the namespace rules) JSON was going to win over XML for a developer in JavaScript, certainly.. and then the format is also trivially mappable to almost any other language as JavaScript is so devoid of types.
At this point, if I don't need efficiency I just use JSON as my wire format. Need to integrate a C++ card game engine with emscripten? I expose 2 functions, one that dumps all as JSON and one that accepts legal moves. The JSON syntax is pretty irrelevant except for light debugging - however, the easy mapping without fussing over many alternate representations is quite relevant
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.
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.
> 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.
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.
> But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself.
An example of where this is an issue is using version as a name space ie tags with the form “<v2:customer>” and apply xslt on “<customer>”. Since they’re strings, they don’t match. The standard xslt solution is to strip the namespace from offending elements. Or change all your xslt. I learned this in an app with a few 100k lines of xslt.
An example of where this is an issue is using version as a name space ie tags with the form “<v2:customer>” and apply xslt on “<customer>”. Since they’re strings, they don’t match. The standard xslt solution is to strip the namespace from offending elements. Or change all your xslt. I learned this in an app with a few 100k lines of xslt.
[deleted]
Interesting, thanks
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:
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.
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>
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.
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 : (
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 : (
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
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.
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.
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.
Interesting how the embedded XML syntax resembles today's JSX, I wonder if it took inspiration from it.
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.
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.
And JSX is renderer-agnostic (and even implementation-agnostic). You can use it to render anything from CLIs to smart TV interfaces.
I'm curious what I'd use JSX for in a CLI :)
The same single direction data flow/declarative render model as you’d use for DOM! The most prominent example is Ink: https://github.com/vadimdemedes/ink
It's listed as Prior Art on JSX's Github
https://facebook.github.io/jsx/#prior-art
https://facebook.github.io/jsx/#prior-art
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.)
(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.)
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.
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.
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?
Because it unnecessarily complicates the grammar and because there are better ways to accomplish the same thing.
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...
https://docs.microsoft.com/en-us/dotnet/visual-basic/program...
I liked this syntax so much I now use XQuery for everything
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)
I loved E4X in Actionscript.
Fun fact: e4x is part of why JS has for(of) instead of something more sensible
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.)
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.)
Sigh. As the person who came up with for(of) I can say that's not the reason.
for(in) existed in JS, and the semantics were never going to be changed, that wasn't something that was on the table or was ever considered.
However other languages have syntaxes like:
We couldn't use `foreach` or `for each` as they conflicted with e4x - one directly, the other by being sufficiently similar to not be plausible.
More depressingly for(:) was killed because of the zombie "typed JS" proposal.
for(in) existed in JS, and the semantics were never going to be changed, that wasn't something that was on the table or was ever considered.
However other languages have syntaxes like:
for each (...)
foreach (...)
for ( .. : .. )
We couldn't use `foreach` or `for each` as they conflicted with e4x - one directly, the other by being sufficiently similar to not be plausible.
More depressingly for(:) was killed because of the zombie "typed JS" proposal.
(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.