Re: RELAX NG Marketing
Hi Jeff, > 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.). I guess you could do something along the lines that Tom suggested, and create a transformation to do the laborious task of taking a content model like: (A, B, C) and creating one like: ((A, ((B, C) | (C, B))) | (B, ((A, C) | (C, A)) | (C, ((A, B) | (B, A)))) Of course this becomes greatly complicated by occurrence constraints and the fact you have to watch for the unique particle attribute constraint (non-deterministic content models). Also, you have to take into account the fact that element A might actually come from a different complex type. I think you'd have to incorporate a degree of canonicalisation into the process, perhaps to the extent that you might as well generate the schema automatically from the data model. If you can get away with reordering each instance document just once (e.g. when it's first created), and need to validate the document several times, then I would have thought that option 3 will probably end up being less of a burden than checking the extra cardinality constraints on each validation. But even if you'll need to do the reordering of each instance document more than once, you must be reading the document in as a DOM anyway, to do the schema validation, so perhaps within the code, prior to schema validation, you could rearrange the DOM to create a canonical ordering; at least that way you don't have the overhead of creating two DOMs, as you would with an XSLT transformation. Mind you, I'd try it just with XSLT first, as that's likely to be easier to program and I don't think that the performance hit will be *that* high anyway. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format