Lists Home |
Date Index |
Forgot the link:
> -----Original Message-----
> From: Jeff Lowery [mailto:firstname.lastname@example.org]
> Sent: Tuesday, March 26, 2002 11:50 AM
> To: 'John Cowan'; email@example.com
> Cc: firstname.lastname@example.org
> Subject: RE: [xml-dev] RELAX NG Marketing
> 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. 
> 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
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>