Should you be using RELAX-NG?

Posted by Gavin Terrill on Oct 29, 2007

Sections

Development,

Architecture & Design

Topics

Architecture ,

Technology ,

Domain Specific Languages

Tags

W3C ,

XML Schema ,

RELAX-NG

RELAX-NG (pronounced "relaxing") is an alternative XML schema definition language characterized by being simpler and more elegant than the more generally known DTD or XSD based languages. W3C XML Schemas in particular has garnered a reputation as being overly complex, with XML luminaries such as Tim Bray commenting:

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.

To help condense some of the information scattered around the internet on the virtues on RELAX-NG, Griffin Brown recently listed 10 reasons to model XML with RELAX NG , not W3C XML Schema. The list includes:

1. "A better spec means better interoperability".
2. "Availability of a compact syntax" (RELAX-NG supports a DSL that concisely expresses constraints without resorting to pointy brackets).
3. "The specification is a stable ISO standard".
4. "No PSVI" (PSVI is considered harmful).
5. "No content defaulting".
6. "Better data typing support".
7. "More sophisticated modeling".
8. "More sophisticated grammatical validation".
9. "Instances have no dependency".
10. "Growing consensus".

Converting XSD files to RELAX-NG (.RNG) can be accomplished using the "Sun Multi-Schema Validator" tool, which produces verbose format .RNG files. Trang can then be used to convert to these to the compact form.

1. Back to top

   Must be 10x easier than the incumbant

   by Noah Campbell

   ...before you'll see folks switch.
   
   Brown points out 10 things that are arguably qualitative, not quantitative. XML-Schema, if anything, is complex, but not necessarily deficient.
   
   I'm all for adopting standards that are easier to approach since xml schema modeling is very important. Again, it's hard to justify a switch in schema tooling when a good deal of infrastructure won't support it.

   Reply

2. Back to top

   Re: Must be 10x easier than the incumbant

   by Jean-Jacques Dubray

   I agree with Noah. I am not a specialist of relax-ng by any means but a quick look at the spec seem to indicate that the extensibility of the language are weak (foreign elements and attributes seem to be limited to ##other namespace). If this is the case, this is a severe limitation and setback incompatible with SOA.
   
   I did not see any performance comparison, it would be interesting how validation compares in both cases.
   
   I agree that XML Schema is complex (tools somehow mitigate it) but I need this complexity. The question is for the casual designer of schemas (say a few schemas a year), what is the best approach for him or her? is a tool enough? Do we really need a new syntax?
   
   I like the vision of David Chappell that seem to indicate that XML, WSDL, XSD, BPEL... are the byte code level of the technology. I am not sure we need more byte code level technologies.
   
   Not convinced so far...

   Reply

3. Back to top

   Re: Must be 10x easier than the incumbant

   by Jose Alberto Fernandez

   We use RelaxNG compact extensively in our systems. It is so easy to write that there is no need for complex tools. The Java XML parsers support it perfectly.
   
   You can import definitions, use multiple name-spaces, use overriding of definitions and much more with ease. And almost any human with minimal knowledge of context-free grammars can understand them easily. It has the correct level of syntax sugar necessary to allow you to express complex schemas succinctly.
   
   I do not wish XSD on anyone, not even on my worst enemy.

   Reply

4. Back to top

   Re: Must be 10x easier than the incumbant

   by Joshua Graham

   +1. "If WSDL is a turd, then XSD is the dodgy curry that makes it stink" - me.

   Reply

5. Back to top

   And embed Schematron for XPath-based rules

   by Joshua Graham

   ...very nice.

   Reply

• Older >