Lists Home |
Date Index |
"Henry S. Thompson" wrote:
> > Can someone extend it:
> > <!ELEMENT a' ((b,c)+,c,b)>
> > If so, that could really confuse most element-triggered processing
> > specifications.
> Not sure what you mean. This is a difficult case to start with (it's
> DT/DD under another name, a well-known pain for XPath). But if I
> tackle it in the usual way, i.e. by recursion over the nodelist
> picking of b+c pairs, it will work just fine, i.e. stop after the b+c
> pairs run out, ignoring the new material.
Given the content model:
<!ELEMENT a (b, c)>
Here's the usual way to handle it:
This is guaranteed to produce valid XHTML given the original content
model. But the following extension will trick it into producing invalid
<!ELEMENT a' ((b,c)+,c,b)>
> Which, I should clarify, is what I take it the MNTDV is -- processes
> designed to work with the unextended type should work with instances
> of the extended type just as they would have if the extra material
> wasn't there.
That isn't the case with the process above. The only way this could work
is if there were a way of asking the schema processor to produce an
infoset that conformed to the original content model by filtering out
anything extra. But you would want an interoperable definition of
"anything extra" because there could be an ambiguity problem with some
<!ELEMENT a' ((b,c)+,b,c,b)>
Is the latter b,c extracted from the original content model or "extra
stuff" that should be filtered out?