This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Back to Basics: XPath and Context Node
- To: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>
- Subject: RE: Back to Basics: XPath and Context Node
- From: Kay Michael <Michael dot Kay at icl dot com>
- Date: Tue, 9 May 2000 09:41:24 +0100
- Cc: John Robert Gardner <jrgardner at atla-certr dot org>
- Reply-To: xsl-list at mulberrytech dot com
> sect 1: . . . "Several kinds of expressions change the
> context node; only
> predicates change the context position and context size."
>
> Q: by implication, then, predicates do not change the context
> node?
No, it doesn't say that and it doesn't mean that.
>
> Sect. 2: "child::para selects the para element children of the context
> node."
>
> Q: so, if I have this xsl
>
> < . . . .std. header stuff and PI . . .>
> <xsl:template match="/">
> <xsl:apply-templates />
> <xsl:template>
>
> <xsl:template match="child::para or child::*">
> ---some stuff ---
> </xsl:template>
You can't say this because you can't use "or" in a pattern. Perhaps you mean
"|".
>
> The context node for my child:: matches is the root
> "/", yes?
No, the rules for pattern matching are that a match is attempted with each
ancestor of the node being matched (plus the node itself). This is in XSLT
section 5.2, first para.
> my location path is essentially redundant b/c child::* includes
> all para's anyway, obviating the "or," right?
Yes, if you read "or" as "|".
>
>
> Sect 2.1: Location steps: . . ."The final node set is the node-set
> selected by the location step"
>
> Q: reading the BNF preceding this question, am I right that
> location steps only occur in RelativeLocationPaths (cf. [3]
> immediately before 2.1)?
Steps are used directly only within a RelativeLocationPath but a
RelativeLocationPath forms part of many other constructs including an
AbsoluteLocationPath.
And, then, is the location
> step in this
> case <=> with the "location path" -- same thing as?
No, the path is a sequence of steps.
>
> Sect 3.2 Function calls: . . . "A FunctionCall expression is
> evaluated by
> using the FunctionName to identify a function in the
> expression evaluation
> context function libarary, evaluating each of the arguments,
> converting
> each argument to the type required by the function, and
> finally calling
> the funtion, passing it the converted arguments."
>
> Q: Anyone courageous to unpack this-- particularly the
> astounding
> concatenation: "the expression evaluation context function
> libarary"? In the absence of an example here, it's not clear to
> me what exactly the "function call" is, unless --and I am
> certainly wrong here but it's all I can think of in my
> non-programmer's mindset-- "xsl:call-template"?
A function call is something like number('23.4') or true() or
contains(.,'fred').
The "expression evaluation context function library" means the function
library associated with the context in which the expression is evaluated, a
concept explained in XPath section 1.
>
> And finally, in due deference to nomenclature issues,
> "xsl:call-template"
> or "xsl:variable" or xsl:choose -- these are properly called
> XSL elements,
> xslt elements, xslt functions, xslt operators, xslt commands, xslt
> template types, xslt transformers ("more than meets the eye")
They are all XSL elements, in fact the ones you list are all XSL
instructions, which is a subtype of XSL elements. But not all XSL elements
are instructions, e.g. xsl:template isn't.
Mike Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list