[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] When to use conditional constructions?


Subject: Re: [xsl] When to use conditional constructions?
From: Graydon <graydon@xxxxxxxxx>
Date: Mon, 31 Mar 2014 12:32:19 -0400

On Mon, Mar 31, 2014 at 05:08:09PM +0100, Michael Kay scripsit:
> > While we're extending XPath, can we have support for named, referenceable
> > predicate definitions?  
> 
> Isn't that the same thing as a function?

The case I'm thinking of is something like

<xsl:template
match="section[heading][body/table][body/para[following-sibling:table]][not(body/para[preceding-sibling:table])]">....</xsl:template>

<xsl:template
match="section[heading][body/table][body/para[following-sibling:table]][body/para[preceding-sibling:table]]">....</xsl:template>

<xsl:template
match="section[heading][body/table][not(body/para)]]">....</xsl:template>

Where one's making a distinction between "the normal sections", "the
normal sections with normal tables", "the sections with weird tables",
and "the stuff that really shouldn't be a section but no one has had a
better idea"; it would be very convenient to be able to give the
(generally longer and more complex than presented) predicates meaningful
names and be able to lump them together, since the test tends to get
re-used at least a couple of times.  (Once for processing and once for
the table of contents and maybe once or twice where children are being
processed and the distinction needs to be maintained, so it would be
helpful to be able to go "ancestor::section[%normalSection%]" (or some
less awful syntax...))

<xsl:template
match="section[user:isNormalSection(.)]">...</xsl:template>

and so on seems heavy and expensive compared to effectively a macro
language for predicates; the perceived problem is that the predicates
get long and tough to manage, rather than lack of expressiveness or
power in the predicates.

-- Graydon


Current Thread
Keywords