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

Re: [xsl] except


Subject: Re: [xsl] except
From: Graydon <graydon@xxxxxxxxx>
Date: Sun, 2 Feb 2014 22:54:56 -0500

On Sun, Feb 02, 2014 at 11:34:00PM +0100, Imsieke, Gerrit, le-tex scripsit:
> On 02.02.2014 22:50, Graydon wrote:
[snip bewilderment]
> >if I want all the descendant elements without any of the descendant
> >elements who happen to be heading elements.
> 
> If you want that and if you insist on using except instead of the
> classic filtering by predicate,
> 
>   descendant::*[not(self::heading)] ,

Which would be utterly preferable in this simple case.

I'm thinking about some past requirements to build a table of contents
out of a list of documents with odd, per-product, exceptions -- this
product doesn't get any TOC references to the tables in chapter four, sort
of thing -- and thinking that it might be easier to automatically
generate the expression using except.  (I'm not sure this is a good
thought, but it's the thought.)

> you can easily write:
> 
>   .//(* except heading) ,
> 
> which (partially) expands to
> 
>   ./descendant-or-self::node()/(* except heading) .

Something to keep in mind; thank you.

> I think you'll just have to remember that the sequences on both
> sides of except will be evaluated from the same context.

Just to be clear to the pre-existing bewilderment, you mean that both
the rh and lh operands of except start at the same context node?

(That's what I think you mean.)

> This clear but apparently sometimes counterintuitive semantics of
> except should not change if the expression has some special
> characteristics. [snip]

Well, let me try this again.

3.0 allows more axis references in template matches than 2.0 did; 2.0 is
child and attribute only, 3.0 allows descendant.  (I think it allows all
ForwardAxis axises.)

So

<xsl:template match="descendant::*"/>

is a legal match attribute value.

Leaving any use of except or intersect or union out of it for now just
what does that match mean?  I'm not having any luck with 5.6.3 (The
Meaning of a Pattern) in the spec, which covers child and namespace and
attribute axises, with what looks to me like a special case for
document-nodes, but it doesn't seem to cover descendant or the following
axises, and I'm having some trouble figuring out what nodes such a
template would be expected to match.

-- Graydon


Current Thread