OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] RELAX NG Marketing

[ Lists Home | Date Index | Thread Index ]

Forgot the link:

[1] http://www.topologi.com/public/Schtrn_XSD/Paper.html

> -----Original Message-----
> From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
> Sent: Tuesday, March 26, 2002 11:50 AM
> To: 'John Cowan'; matthew.gertner@schemantix.com
> Cc: xml-dev@lists.xml.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. [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
> -----------------------------------------------------------------
> 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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS