Lists Home |
Date Index |
In cases like this schema authors can use the block attribute to prevent xsi:type assertion from being used in instance documnts. Of course, schema authors first have to be educated on why this is necessary.
Someone should start a series of articles/tutorials designed at making W3C XML Schema more accessible. Or maybe a good book based on real world experiences.
From: Paul Prescod [mailto:firstname.lastname@example.org]
Sent: Sat 6/8/2002 12:29 PM
To: Henry S. Thompson
Cc: Dare Obasanjo; Amelia A Lewis; email@example.com
Subject: Re: [xml-dev] xsi:type and broken contracts
"Henry S. Thompson" wrote:
> Um, no, the content model for dl in XHTML is (dt|dd)*, which will
> cover what your rules produce, and what they produce will look OK
Let's not get hung up on the details of XHTML. There are many content
models of the form (x,y)+ out there. And anyhow, I can come up with
these examples all day.
<!ELEMENT DOC (TITLE, P+)>
The processing rules are set up to presume title precedes all paragraphs
(that's what the schema says, after all). Then someone uses an extension
to add a TITLE to the end.
<!ELEMENT doc (head, body)>
I have a set of rules like this:
Then someone uses an extension or xsi:type to change the content model
<!ELEMENT doc (head, body, body)>
My output will be unexpected. I'm willing to bet that most non-trivial
stylesheets make assumptions of this sort. That is, after all, the
reason you have schemas: to make the input data predictable. If some
random element can appear at the end of a parent element, that random
element can trigger unexpected processing that was intended for the same
element in some different context.
Writing stylesheets that are safe in the face of this sort of trick is
going to be twice as hard as writing ordinary stylesheets. Essentially
you are "re-enforcing" the ordering constraints from the schema. This
also makes my stylesheet more fragile because I have to change it in
lockstep with the input schema.