Dare comments on my post re: RNG vs. XSD

Dare replied to my post on RNG...

He observes is that people use a schema langauge for different things: type-annotating an XML doc to facilitate OO and SQL mappings, validation, and documentation of a format. His point is that XSD is better for the first task and RNG is better for the second task. I certainly agree that RNG is better than XSD at validation. I don't know which is better for type mapping. There are loads of legal XSD things I can do that don't map at all well to the modern OO world, including, but not necessarily limited to: redefine, derivation of complexTypes (or even simple types) by restriction, element substitution groups (which pretty much require GEDs to be OO types too), the fact that I can apply both element and type substitution to the same element at the same time, final for stopping particular kinds of type construction, block for stopping runtime substitution of types and elements, and the fact that final and block options aren't inherited by subtypes. We work around that by not doing those things. There are, presumably, things that I can do with RNG that may be hard to map to other type systems, but as with XSD, I could avoid those things.


Posted Aug 20 2004, 10:05 AM by tim-ewald

Comments

Gia wrote re: Dare comments on my post re: RNG vs. XSD
on 08-20-2004 10:20 AM
Out of 3 OO maping problems you mention, only redefine is a major one. Example of successful xsd->oo mapping that handles restrictions and substitution groups can be seen here:

http://davidbau.com/archives/2003/12/18/the_design_of_xmlbeans_part_3.html

Tim wrote re: Dare comments on my post re: RNG vs. XSD
on 08-20-2004 10:34 AM
I guess the question is what the phrase "map at all well to the modern OO world" means to you. Yes, one can do a complete mapping of many of these things, as the reference you give makes clear. I've done work on mapping substitution groups by making global elements into generic C# types that are parameterized based on the C# type representing the appropriate XSD type. With that model, you can indeed implement the parallel type and element substitution hierarchies. I ignored the final/block issue: these values aren't inherited, so you can have type C derived from B derived from A, where C is not substitutable for B but both are substitutable for A. (A problem that this article doesn't address, as far as I can see).

The real issue is, do any Java or C# programmers want to code against this kind of object model? Do we really want to drive this kind of XSD complexity into our OO application code? Certainly people working with XPath and XSLT generally don't want to deal with this kind of complexity in an XML dialect. I can't imagine doing it in Java or C#. But I could be in the minority. Thanks for the reference. :-)

Tim-

Dare Obasanjo wrote re: Dare comments on my post re: RNG vs. XSD
on 08-20-2004 12:17 PM
David,
Sure its possible to design some convoluted API that sticks as closely to the XSD type system as possible. However it is unclear to me why anyone would want to program against that instead of against the XML infoset directly (System.Xml.XmlDocument) or business objects hydrated from an XML stream (System.Xml.Serialization.XmlSerializer).

The obsession with XSD fidelity in XML Beans always struck me as a design flaw.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?