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