Cart
[Home] [By Thread] [By Date] [Recent Entries]
If the proposed solution doesn't address the requirements, then there is no choice but to seek a different solution. It's that simple. True, the "different" solution may involve hacking the original. This is the approach one standards body I know of seems to be taking. Their data model requires unordered element content (everywhere). They have an XML Schema for this data model, but the XML Schema language severely restricts the ability to specify unordered content. Their workaround has been to use unbounded model groups. That works, so long as you don't care about validating the cardinality of children. Since it's kinda important in most cases, though, the current proposed workaround to the workaround is to add appinfo annotations to each child element that specifies its true cardinality. A Xerces plugin is then used to check the cardinality of children based on the appinfo annotations. Needless to say, this is a truly ugly hack. And tool dependent. As an aside, similar solutions have been proposed elsewhere using Schematron rules in appinfo annotations. These may be ugly, too, but have at lease some appeal if only because you get added Schematron constraint checking in the bargain. [1] Inelegant as appinfo cardinality annotations may be, I have suggested three alternatives, none of which are being accepted with open arms: 1) add a constraint to the data model that requires children to be ordered. (I have sympathy for those who wish not to enforce artificial constraints on their data model.) 2) Use RELAX-NG + XSD datatypes. (Politically incorrect.) 3) Fix the cardinality definitions in the XSD schema and use an XSLT transform to order children prior to validation. (Seems simplest, but what's the performance hit for a large document? Maybe Tom Passin can answer that one.). There's probably a couple of other options I'm not thinking of. Feel free to share. -- Jeff
|
