[
Lists Home |
Date Index |
Thread Index
]
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
|
