Home
Feedback
FAQ
Getting Started
Discussions
Site operation discussions
Recent Posts
(new topic)
Departments
Courses
Research Papers
Design Docs
Quotations
Genealogical Diagrams
Archives
A series of code snippets gives you a taste of how E4X can be used to manipulate XML.
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
http://www.crockford.com/JSON/index.html and json the fat free alternative to xml
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.
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.
myHackHack
From Jon here
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.
The nightly builds of Mozilla also support E4X in HTML.
Recent comments
23 weeks 23 hours ago
23 weeks 1 day ago
23 weeks 1 day ago
45 weeks 2 days ago
49 weeks 4 days ago
51 weeks 1 day ago
51 weeks 1 day ago
1 year 1 week ago
1 year 6 weeks ago
1 year 6 weeks ago