Re: Questions on the new XSL spec (section 2.6)

David Schach wrote:

> > These are kind of confusing
> > when used as match patterns; one case is definitely useful:
> >
>         [David] - Can you be more specific.  What does it mean to use
> ancestor in a match pattern?

2.6.2 says:

"[2] MatchExpr ::= SelectExpr

A match pattern must match the production for MatchExpr; a node matches
the match pattern if the MatchExpr returns true when evaluated
with that node as context.

The result of the MatchExpr is true if, for any node in the document
that contains the context of the MatchExpr, the result of evaluating the
SelectExpr with that node as context contains the context of the
MatchExpr. Otherwise the result is false."

and

"[20] AncestorExpr ::= 'ancestor' '(' MatchExpr ')'

The result of an AncestorExpr is the first ancestor of the context of
the AncestorExpr such that MatchExpr, when evaluated with that ancestor
as the context, has a result of true. If there is no such ancestor, the
result is the empty node set."

If you follow these definitions through, I believe the result is that

ancestor(P)

matches a node if it is the P ancestor of some node (ie it matches a
node if the node matches P and has at least one child).

I did say it was confusing.  Something like foo/ancestor(bar) is even
more confusing...

> >  id("foo")
> >
> > matches an element with ID "foo".
> >
> > >     Can these patterns appear in a SubtreeExpr? In other words, can they
> > > appear as a "child" of another pattern? For example, is
> > > 'a/b/ancestor(c)/d' a permitted pattern?
> >
> > Yes.
> >
>         [David] - This construct is not permitted in the Microsoft XSL
> implementation. The ancestor must be on the left side of the /.

How about id()? Do you support something like foo/id(@ref)?

James


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list