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

> On 12-07-06 05:29 AM, Hugh Cayless wrote:
> 
<snip/>
> >
> > What if *[@id='foo'] is immediately preceded by an element or an
> > opening tag? What if *[@id='foo'] is the root element?
> 
> Good point. In that case, perhaps we should be returning an XPath expression for the first actual thing which can be described in XPath (element, character in a string value, etc.)?

Well, some thoughts here: the first is that while I'm acting like pointers are functions, they aren't really. They aren't instructions written in any extant programming language and what they are meant to do is address pieces of a document *in context* so that those pieces can be operated on in some way (by a real programming language). Second, what does left(/) return? Or right(/)? Finally, I'd argue that there's a problem with addressing individual characters using XPath: really, you can only address nodes in a way that allows them to be manipulated in place. To get at individual characters, you have to employ functions that strip them of their context (i.e. return atomic values), like substring(), substring-after(), and so-on. So XPath isn't by itself sufficient.
> 
> I do see another problem with allowing for string-ranges within attributes: you could specify a left() which is (say) in the middle of an attribute, and a right() which is in the middle of the attribute's parent element's text content, thus creating a range which can't be turned into a meaningful fragment. So perhaps we should be leaving attributes out of this.

I think attributes are a non-starter. They're addressable via XPath for a start, and left() or right() can have no meaning with regard to them, because attributes are by definition un-ordered.
> 
> It strikes me that what you say regarding the requirement for implementations to be so context-specific that they would in fact have different effects in different contexts (a string-range in the context of XInclude would result in something different from the same XPointer expression(s) in other contexts, whatever they might be) is a fatal flaw. If TEI XPointers are a sort of API which we hope will be implemented in different processor contexts, they surely have to be specified in such a way that they can produce similar results in all those contexts?

They are an API for addressing parts of an XML document. Once you have the addresses, you can do whatever you want with them. Put another way, they are a Domain Specific Language whose implementation depends on the programming language and context in which they are being used.

Thanks for helping me think this stuff through!

Hugh

> 
> Cheers,
> Martin
> 
>> 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 */
>> 

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