On Jul 6, 2012, at 8:05AM, Martin Holmes wrote:

> This looks like an excellent start. I have one question about this bit:
> 
> "Instead of saying left() and right() return Points, it might be better to declare them as returning nothing, but instead setting a location pointer available to other functions."
> 
> Why do you say this? I don't really see in what context a location pointer could be set; this suggests either passing in an actual pointer (a parameter by reference) which would then be set to something, or having a global variable of some kind which could be set by the function, but I don't see how another XPointer function could reliably access either of these things except in a very language-specific manner.

It will have to be context-specific. My starting-point for this was XInclude. You can't Xinclude a Point, therefore either a bare left() or right() has to be illegal in the context of XInclude or we need to define them in a way that plainly makes them not useful in that context. Assume a pointer like:

range(left(foo),right(bar))

Any implementation will have to decide what to do with left() and right(). In the context of XInclude, this would mean something like "return a sequence of nodes containing the element with xml:id="foo", the element with xml:id="bar", and everything in between". In another context, it might mean "wrap this sequence in a <span class="hghlight"> tag". If we were using left(foo) to say "there's a line-break tag that should go here" on the other hand, we'd mean "insert <lb/> immediately before *[@id='foo']".

In any case, all of these pointer functions are going to have to be compiled into runnable code by their implementations, so all behaviors will be language-specific in the end. What I don't want to do is claim they return things that don't exist.
> 
> I think functions which return points need to return something specific. Perhaps we can define what that specific thing is? Could left() actually not return a point, but return the first character following the point; and right() return the last character before the point? This would have the virtue of being expressible in XPath; they would also allow for selection of a string-range within an attribute value.

What if *[@id='foo'] is immediately preceded by an element or an opening tag? What if *[@id='foo'] is the root element?

Best,
Hugh

> 
> Cheers,
> Martin
> 
> On 12-07-06 04:35 AM, Hugh Cayless wrote:
>> Hello everyone, I had essentially no time at all in June to do anything but mull this over, but I now have the beginnings of a document with notes toward requirements and a specification. You can view it at https://docs.google.com/document/d/1JsMA-gOGrevyY-crzHGiC7eZ8XdV5H_wFTlUGzrf20w/edit
>> 
>> It's open to comments only at the moment, but I'm happy to let anyone who wants to edit it.
>> 
>> Best,
>> Hugh
>> 
>> /**
>>  * Hugh A. Cayless, Ph.D.
>>  * NYU Digital Library Technology Services
>>  * http://papyri.info
>>  */
>> 

/**
 * Hugh A. Cayless, Ph.D.
 * NYU Digital Library Technology Services
 * http://papyri.info
 */