Re: XPath Serialization

On Mon, May 29, 2000 at 10:25:17PM -0700, Michael Dyck wrote:
> At 00/05/23 11:04 -0700, John Boyer wrote:
> >
> > Attached is the latest version of the XPath serialization spec.  The
> > following changes were made:
> >
> > 2) Added the function here() to the XPath function library based on requests
> > by the group at and after the Victoria FTF.  You want to have a look at it,
> > though, because it is defined slightly differently than in the current
> > XPointer draft.  Basically, they define it to return the element containing
> > the attribute or text node that bears the Xpath expression.  I changed that
> > to returning the actuall attribute, text or other node (if you want the
> > element, you can get the parent, but if you are given an element, but it has
> > more than one attribute bearing an Xpath, then there is room for ambiguity.
> 
> Then, on Fri, 26 May 2000 18:04:42 +0200, Daniel Veillard wrote:
> >
> > well XPointer Last Call has finished and we are in the last steps
> > toward moving XPointer to Candidate Recommendation status. Unfortunately
> > this seems too late now to get this rather radical change to XPointer,
> > and I suggest you rename your function call. I also suggest you send
> > your proposal for extension of the XPath library to the XPath comment
> > list so that it gets added (but under a different name you should suggest)
> > in the next revision of XPath,
> 
> If it makes any difference (which I suspect it doesn't), I suggested

  It does ...

> this change in the semantics of here() ten months ago. See
> http://lists.w3.org/Archives/Public/www-xml-linking-comments/1999JulSep/0007.html,
> section 5.3.3.

  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
 I agree that the current definition is tied to the notion of "link" not 
specified at the XPointer level.

 However I would suggest not exporting a different version of here() 
in your API until this get resolved, 

 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).

   thanks,

 Daniel

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe

Received on Tuesday, 30 May 2000 03:15:48 UTC