Re: Back to Basics: XPath and Context Node

[Michael Fuller <msf at mds dot rmit dot edu dot au>]

On Mon, May 08, 2000 at 09:32:19PM -0400, John Robert Gardner wrote:
> 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, you're sorta reading the implication backwards.  Try this paraphrase:
    "Several kinds of expressions change the context node, but do
    not the context position and context size; only predicates also
    change the context position and context size."

Section 2.4 makes this clear:
    "A predicate filters a node-set with respect to an axis to produce
    a new node-set. For each node in the the node-set to be filtered,
    the PredicateExpr is evaluated with that node as the context node,
    the number of nodes in the node-set as the context size, and with
    the proximity position of the node in the node-set with respect to
    the axis as the context position; [...]"

Basically, predicates establish a new context -- with a new context node
and a new context position -- for each node in the node-set they're filtering.
	

> 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>
> 	
> 	The context node for my child:: matches is the root "/", yes? and
> 	my location path is essentially redundant b/c child::* includes 
> 	all para's anyway, obviating the "or," right?

Right, child::* matches _all_ "children" of the context node;
child::para is a subset of child::*.
In this case, the context node is "/", so there will be exactly
one child node to be matched, the document element.

> Sect 2: A relative location path consists of a sequence . . . separated by
> 	/. . . . An absolute location path consists of / optionally
> 	followed by . . ."
> 
> 	Q: anything beginning with / is an absolute path, and nothing that
> 	doesn't begin with / can be an absolute path, therefore it is relative
> 	(wish I'd remembered my BNF foray in my one AI class . . .)?

No, an absolute path can also start with "//"; see productions [2] and [10].

> Sect 2.1: Location steps: . . ."The final node set is the node-set
> 	selected by the location step"

I think that would make more sense read as "selected by the last 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)?

Yes.

> 	                          And, then, is the location step in this
> 	case <=> with the "location path" -- same thing as?

A location path is composed of one or more location steps.
Consider:
    /step1/step2/step3
"/step1/step2/step3" is a location path.
"step1", "step2", and "step3" are location path 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"?

An XPath expression is evaluated with respect to a "context." (See the
_Introduction_, para. 5). Part of that context is a "library" of functions
that may be used in the expression.  XPath specifies a standard function
library, but applications (such as XSLT, XPointer, probably the W3C query
language) and users may supply extra functions. (For example, xsl's
document(), XPointer's range(), xt's xt:node-set(), or some user's
myfunx:calculateEaster()). 

So this sentencejust says: find the function named "FunctionName"
from the set of functions that are available, evaluate the argument
or arguments, if necessary convert the results of that evaluation
to the type required by function, then call the function, passing
it the desired arguments. Easy. :-)

>                   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"?

No, no, 100% no. "Wrong way, go back." See the above.

> 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") -- what's
> the accepted word for that xsl-namespaced-thing?

"XSLT instructions" if they can be part of a template body -- such as
<xsl:copy-of> -- and "XSLT top-level elements", if they can be children
of the stylesheet document element -- such as <xsl:template>.


> I've also tried various FAQ's on these points, but what I'm really trying
> to get at is a good oldfashioned commonfolks' definition type explanation
> and example (and, not wanting to curry disfavor, but the shipping time on
> my efforts to procure a certain book are not adding up to the par set by
> my colleagues herein, save, heaven-forbid, Australia ;-)).

Sorry, John, I expect it's available here, too. :-)
You'll just have to make do with the W3C Recs, XSL-LIST, and XML-DEV.

Michael
____________________________________________________________________________
Multimedia Databases Systems,                  Phone:      +61 3 9925 4148
RMIT University                                Fax:        +61 3 9925 4098
Level 3, 110 Victoria St,                          msf@mds.rmit.edu.au
Carlton 3053, Australia.                    http://www.mds.rmit.edu.au/~msf/


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