Tim Bray Says RELAX

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."

Comments

Re:Just sit back...

[ubernostrum]

What kind of programmer can't use XML effectively anyhow...oh wait... (No, I didn't read TFA!)

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 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

[Peter Cooper]

Check out YAML.

Re:it's a rather straightforward observation

[radtea]

XML was designed with people in mind, which is why it's easier for people to read and manipulate than your traditional binary file format.

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

[SimHacker]

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 about the design and development of Relax NG.

-Don

James Clark wrote about maximizing composability:

First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.

Clark describes the derivative algorithm's lazy approach to automaton construction:

I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the "derivative"-based approach in JTREX as lazily constructing a kind of automaton where states are represented by a canonical representative of the patterns that match the remaining input.)

The Relax NG derivative algorithm is implemented in a few hundred elegent declarative functional lines of Haskel, and also in tens of thousands of lines and hundreds of classes of highly abstract complex Java code.

Clark's Java implementation of Relax NG is called "jing", 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 really is. The Java code must explicitly model and simulate many Haskel features like first order functions, memoization, pattern matching, partial evaluation, lazy evaluation, declarative programming, and functional programming. That requires many abstract interfaces,, concrete classes and brittle lines of code.

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:Maximizing Composability and Relax NG Trivia

[John Whitley]

That's an awful lot of cutting and pasting just to take a worthless jab at the Java language.

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. ... An Experiment in Software Prototyping Productivity. It's a fascinating read if you aren't already familiar with how different programming in Haskell is from many currently popular languages. I highly recommend delving into Haskell for any dedicated developer. Even if you don't find yourself developing in Haskell on a daily basis, the experience will positively impact how you think about code, and bring new conceptual models and patterns into your toolbox.

Re:Wait wait wait

[Anonymous Coward]

No, this is:

start =
    element addressBook {
        element card {
            element name { text },
            element email { text }
        }*
    }