Re: XPath Serialization

Daniel Veillard wrote:
> 
>   Assuming that both suggested changes are actually the same we may do a last
> pass on this. Help me make sure both of you were suggesting the exact same
> change: if I understand properly:
>      here() should be the first containing node at an Infoset level,
>      be it attribute, text, PI etc ... instead of the current definition

Yes, I think that's equivalent to what I was suggesting.

>  I'm also wondering how here() as defined in XPointer as the position for
> the localization of that expression can be compatible with a here() function
> at the XPath level, since the XPath expressions being interpreted don't
> have an "a priori" location (they may come from an XPointer expr embedded in
> the document, being part of an external XSLT stylesheet, or having being sent
> as part of of a query on the document from something without XML context).
> 
>  A small explanation on how an XPath version of here() can be compatible
> with the behaviour defined in XPointer would certainly fasten the resolution
> of the issue. Currently here() is defined as to return an error if such
> an XML context cannot be found. And there is nothing in XPath (to my
> knowledge) allowing to find the context of an interpreted expression
> (it was precisely added to XPointer since not available in XPath).

I don't think there can be "an XPath version of here()", for the reasons
you give. Although XPointer section 3.2 claims that [the structure of] the
XPointer and XPath evaluation contexts are identical (except for the
generalization of nodes to locations), it is clear that here() cannot be
evaluated with respect to such a context; the required information is not
there. Thus the XPointer evaluation context must actually contain an extra
item, just for here(). [I also pointed this out 10 months ago: see Section
4.1 of my comments.]

In retrospect, it might have been simpler to introduce the concept of
"here" as a variable. That is, when an XPointer evaluation context is
initialized (XPointer section 3.2), its set of variable bindings includes
a binding of the variable name "here" (or "HERE" or "_HERE_" or whatever)
to the appropriate node-value, if any. (In fact, it occurs to me that you
could use that mechanism to define the function here(), without having to
add another item to the XPath context.)

Ditto those two paragraphs (mutatis mutandis) for the origin() function.

-Michael Dyck

Received on Wednesday, 31 May 2000 01:34:10 UTC