[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RELAX NG Marketing

c 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.



Jeni Tennison


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.