Tim Bray Says RELAX 180
twofish writes to tell us that Sun's Tim Bray (co-editor of XML and the XML namespace specifications) has posted a blog entry suggesting RELAX NG be used instead of the W3C XML Schema. From the blog: "W3C XML Schemas (XSD) suck. They are hard to read, hard to write, hard to understand, have interoperability problems, and are unable to describe lots of things you want to do all the time in XML. Schemas based on Relax NG, also known as ISO Standard 19757, are easy to write, easy to read, are backed by a rigorous formalism for interoperability, and can describe immensely more different XML constructs."
Re:Just sit back... (Score:5, Informative)
Helpful hint for understanding the above: Tim Bray, author of TFA, is one of the guys who originally developed and spec'd out XML. Really. His name's on the spec [w3.org] and everything. So if he says that a particular XML tool has problems, it's probably a good idea to take him at his word ;)
Re:it's a rather straightforward observation (Score:5, Informative)
Re:it's a rather straightforward observation (Score:3, Informative)
Err... no.
XML was a step back from SGML's "human-friendly" clever tricks. XML was intended to be easy to PARSE, not easy to read.
Maximizing Composability and Relax NG Trivia (Score:5, Informative)
Tim Bray is right, and he couldn't have put it better: W3C XML Schemas (XSD) suck. The reason Relax NG is so much cleaner and more powerful than committee-designed XML Schemas, is that it's based on a sound mathematical foundation (tree regular expressions, or "hedge automata theory"). While XML-Schemas suffer from ad-hoc design, committee-burn, lack of focus, and half-baked attempts to solve too many unrelated problems.
Here's some interesting stuff from my blog [donhopkins.com] about the design and development of Relax NG [oasis-open.org].
-Don
James Clark [oasis-open.org] wrote about maximizing composability:
Clark [oasis-open.org] describes the derivative algorithm's lazy approach to automaton construction:
The Relax NG derivative algorithm [thaiopensource.com] is implemented in a few hundred elegent declarative functional lines of Haskel [thaiopensource.com], and also in tens of thousands of lines and hundreds of classes of highly abstract complex Java code [thaiopensource.com].
Clark's Java implementation of Relax NG is called "jing [thaiopensource.com]", which is a Thai word meaning truthful, real, serious, no-nonsense, and ending with "ng".
Comparing the Java and Haskell implementations of Relax NG illustrates what a wicked cool and powerful language Haskell [haskell.org] really is. The Java code must explicitly model and simulate many Haskel features like first order functions [wikipedia.org], memoization [wikipedia.org], pattern matching [wikipedia.org], partial evaluation [wikipedia.org], lazy evaluation [wikipedia.org], declarative programming [wikipedia.org], and functional programming [wikipedia.org]. That requires many abstract interfaces, [wikipedia.org], concrete classes [wikipedia.org] and brittle [wikipedia.org] lines of code [wikipedia.org].
While the Java code is quite brittle and verbose, the Haskell code is extremely flexible and concise. Haskell is an excellent design language, a vehicle for exploring complex problem spaces, designing and testing ingenious solutions, performing practical experiments, weighin
Re:Wait wait wait (Score:1, Informative)
start =
element addressBook {
element card {
element name { text },
element email { text }
}*
}
Re:Maximizing Composability and Relax NG Trivia (Score:3, Informative)
For many problem domains, it often doesn't matter what language you throw up against Haskell -- the Haskell program will often be smaller by one or more orders of magnitude (for a sufficiently rich/interesting program, anyways). The grandparent poster didn't even craft the example in question; Java was just the vicitm-elect of this particular case. I'll observe that even if the Java program there could be made shorter by an order of magnitude (!!), it would still be an order of magnitude larger than the Haskell implementation.
Although it's a bit long in the tooth now, Paul Hudak and Mark Jones wrote a paper that surveys the results of a Naval Surface Warfare Center prototying study comparing a number of different programming languages. See Haskell vs. Ada vs. C++ vs. Awk vs.