Introduction to E4X

Jon Udell posts a nice intro to E4X (running on Rhino).

A series of code snippets gives you a taste of how E4X can be used to manipulate XML.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

maybe of interest: E4X in ruby

An almost recent article about an E4X-like api implementation in ruby, is here


well it seems to me that serializing xml to json gives you a lot of these capabilities anyhow
and json the fat free alternative to xml

Functional alternatives

This looks like cool syntax to query and mutate XML, but as the above Ruby example shows, this is really just syntactic sugar for the DOM. Fundementally, there weren't any real innovations, just bloat of syntax. An explicit goal of E4X is to keep the developer ignorant of what's going on, and I'm not sure if that's a good thing. The developer should have abstractions to make things easier, but that doesn't mean they should be ignorant.

I'm personally partial to the functional approaches to XML manipulation. Usually these are more flexible and result in shorter code. One of the simplest and IMO most elegant of these is SXML. All SXML does is parse an XML document into a list in Scheme. From there, you can use whatever list manipulation techniques you want. It's suprisingly intuitive if you're used to list manipulation. The user can define his own combinators to make it more convienent, but very often different combinators will be needed for different programs, so none of these are included by default.

Another approach, implemented in Haskell, is to define a combinator library for XML trees, which are stored in internal datastructures not visible to the user. This approach is taken by HaXml, and it usually results in very concise yet clear programs. Another library, HXML, uses the same techniques as HaXml, but it takes advantage of Haskell's lazyness and doesn't parse or store all of the document until it is needed, making programs much more space-efficient. I wonder how useful an XML monad would be; it could emulate mutability and have the same type of concat . map abilities that the List monad does. (am I understanding monads wrong if I think that?)

The third approach is to design a new language that uses XML as a builtin datatype, as XDuce, CDuce, and XMLambda do. These languages are all statically typed, using DTD-like declarations as types, thus allowing for a good degree of validation at compiletime. They also let you inspect XML elements using pattern matching, which is immensely useful and convenient. But I don't really like these because XML shouldn't create new languages; a good language should be able to flexibly and syntactically pleasantly be able to incorporate new ideas about data formats, and most functional languages are already reasonably good at doing that. E4X would probably fit in this category, except it offers none of the benefits of static typing or pattern matching that these languages offer.

"XML Data" in .Net

The .Net approach is to generate an object model from a schema, together with a custom parser that will populate the model from any conformant document. I suppose it's like having a typed DOM. It works in any case if the kind of model you want is characterised by parent-child relationships. But it's still putting the cart before the horse, as far as the relationship between data modelling and data exchange is concerned.

Hackish Alternatives


From Jon here

of interest

if you enjoyed the E4X introduction have a look at Seppia (

it is a fantastic tool built upon Rhino which allows you to use e4x... Seppia is a simple framework to build and deploy any java application.It gains from the sinergy of java and javascript and a minimum set of clear rules to organize their interaction.

in Mozilla

The nightly builds of Mozilla also support E4X in HTML.