David Carlisle wrote:
> I find it's rare to ever need this kind of test though.
>
> If your input may include
>
> <variablelist>
> <title></title>
> </variablelist>
>
>
> and
>
>
> <variablelist>
> <title></title>
> <varlistentry/>
> </variablelist>
>
>
> how do you want them to be processed?
see below
> If the first is an error you can arrange to dtd validate before
> transforming in which case such fragments will never get as far as
> XSLt
> so you don't need to check for them in the pattern.
I could rely on DTD validation, but I don't think I should. My template
says what it matches, and thus states what it can handle: no matter what
which version of which spec/schema(DTD etc) says.
It can handle this type of content model, nothing more. And if a future
version of the schema allows for an extended content model, there will
be no problem with validity in the oputput.
> If validation is not an option it's often simpler to match on the
> simpler * case but then have
> <xsl:if test="not(varlistentry)">...
I already have to test for the existence of the title.
> Do you really have a case where you want to accept both these things
> but
> teh reulting output is so different that you don't want to share a
> template for the two cases?
[very hackish draft of pseudo-code]
<t:template match="variablelist[]">
<t:if test="title">
<t:element name="h{count(ancestor::*)}">
<t:value-of select="title"/>
</t:element>
</t:test>
<dl>
<t:apply-templates/>
</dl>
</t:template>
<!-- quirky -->
<t:template match="variablelist[]/title"/>
In [], picture either a very long XPath1.0 thingy, or an elegant, short
content-model description :)
But beware; sure there are many different ways to handle this, and none
of them *requires* what I propose. But it would make some things simpler.
Tobi
--
Vim users donate.
http://iccf-holland.org/donate.html
Web developers check.
http://www.pinkjuice.com/check/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list