Re: Schema Design: Composition vs Subclassing

> Here the rule comes in force only in the context of an Element1. Then you
> come to the simple logic of has both (att1 and att2) or no att1 attributes.
> SAX makes this easy because it offers all attributes but this is possible in
> cardinality too:
>
> <rule context="Element1">
>   <assert test="not(ch1) or (ch1 and ch2)">no single ch1</assert>
> </rule>
>
> Here you push a Schematron rule onto the stack at the entry to the context.
> The rule consists of three conditions and two logical components. At the end
> of the context (endElement) the rule could be evaluated based on the
> satisfied (or not) conditions. It would be difficult to create a general
> handler for reporting rule violations as they happen (in the above rule the
> entire context would possibly need to be completed before establishing that
> a ch2 element did not exist within that context)
>
> I too am interested to find out if anyone has had a go at this... it sounds
> fun...

Seems to me that this could easily be done with SAX and in fact this is exactly
the way identity constraints work in XML Schema. Since XML Schema's identity
constraint XPath's are limited to "descendants" of the node in which they are
declared this makes it possible to check them with only a SAX parser. I assume
this is exactly the reason why the WG decided to only allow this subset for the
XPath expressions in XML Schema. So, from my understanding this would mean that
co-occurence constraints defined on a context could be validated using SAX as
long as the constraint should be applied to a descendant node. The examples Jeff
provided above would certainly fit this category.
I believe this means that to include Schematron like assertions that only work
on descendant nodes would be fairly easy to integrate in XML Schema while a full
co-occurence constraint engine would be much harder.

Cheers,
/Eddie

Received on Thursday, 25 April 2002 19:40:52 UTC