[
Lists Home |
Date Index |
Thread Index
]
"Henry S. Thompson" wrote:
>
>...
> > Can someone extend it:
> >
> > <!ELEMENT a' ((b,c)+,c,b)>
>
> Yes.
>
> > 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:
<xsl:template match="a">
<dl><xsl:apply-templates/></dl>
</xsl:template>
<xsl:template match="b">
<dt><xsl:apply-templates/></dt>
</xsl:template>
<xsl:template match="c">
<dt><xsl:apply-templates/></dt>
</xsl:template>
This is guaranteed to produce valid XHTML given the original content
model. But the following extension will trick it into producing invalid
XHTML:
<!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
extensions:
<!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?
Paul Prescod
|
