Re: Your comments on XPointer CR

Daniel Veillard wrote:
> 
> Michael,
> 
> thank you for your comments on the XPointer CR specification.
> I case you didn't already got an answer from the Working Group,
> your comments have been taken into consideration and are now listed
> in the XPointer CR Disposition of Comments at:
>    http://www.w3.org/XML/2000/10/xptr-CR-comments.html
> 
> Considering the number of comment you provided you actually got your
> own issues tracking numbers :-)

Neat!

I actually submitted a lot more comments than the 16 that show up on the
Disposition of Comments page. Can I assume that all the others were accepted
as easy editorial fixes?

> As you can see we accepted a majority of your comments and suggestions,
> however there is 3 cases were the Working Group didn't followed your
> suggestion.
> Could you indicate if you accept the Working Group decisions on those issues ?

> --------------------------------------------------------------------------
> [XP88]  MD3: Forms of XPointer
>         which was rejected

The WG said:
> there is a balance between having a very complex BNF or using some prose
> to further refine a simplified BNF. The Working Group prefered to keep the
> BNF as it is, but asking the editors to add a sentence about the extra
> syntax rules not expressed by the BNF. Gavin Nicol objected.

I agree about the need for balance, but:

(1) It seems that XML-related specs generally try to define as much as
possible within EBNF rather than prose. (For instance, look at XML's
productions for CharData and Comment.)

(2) Usually, in a mix of EBNF and prose, the EBNF defines a superset of the
valid strings, then the prose eliminates the invalid strings from that set.
But with the production for StringWithBalancedParens, the EBNF defines a
*subset* and the prose *adds* to that set.

(3) The EBNF to precisely define StringWithBalancedParens wouldn't be that
much more complex than it is already. I think this would do it:

    StringWithBalancedParens ::= Q* ( '(' StringWithBalancedParens ')' Q* )*
    Q ::= ( Char - [()^] ) | '^' [()^]

(Of course, you could use whatever name you liked for "Q".)
I used
    Char - [()^]
rather than
    [^()^]
to avoid two different uses of "^" (literally and meaning 'complement') in
the same production.

> --------------------------------------------------------------------------
> [XP97]  MD12: string-range() Function II 
>         which was accepted

The WG said:
> When the position is outside the document range it generates an XPointer
> scheme part error.

If by that, you mean that the evaluation of the containing XPtrPart fails, I
think that's too harsh. Consider this situation:

    Some on-line document has a sentence that I'd like to refer to.
    It begins "There comes a time" and goes on for 160 characters.
    So I check that that string doesn't occur elsewhere in the document,
    and use:
        xpointer(string-range(/,"There comes a time",1,160))
    Later, however, the document is modified. The sentence I refer to
    is not changed at all, but the author adds another sentence beginning
    the same way. Chances are, my xpointer will now select two ranges of
    the document, which is tolerable. But if the author happens to start
    the new sentence less than 160 characters from the (new) end of the
    document, then (according to the decision above) the whole XPtrPart
    fails, and the XPointer has a sub-resource error.

Instead of failing the whole XPtrPart, two gentler reactions would be:

(1) "Clamp" any outside-document positions to the start or end of the
document, as appropriate. (In my example situation, the xpointer would
select two ranges, regardless of where the new sentence was added.)

(2) Simply disregard any matches that result in outside-document positions.
(In my example, the xpointer would select two or one ranges, depending on
where the new sentence was added.) 

---
And anyway, the WG's response doesn't really answer my question: "What
happens if the third and/or fourth arguments specify positions that lie
outside the string-value of the location?"  Note "location", not "document".
So for example, with this as the document:

    <doc>Thomas <em>Pyn</em>chon</doc>

and this as the xpointer:

    string-range(/doc/em, "P", 1, 7)

Does it select "Pynchon", "Pyn", or nothing?

> --------------------------------------------------------------------------
> [XP100] MD15: Additional Range-Related Functions II
>         we acknoledged the problem, but rejected your proposal, selecting
>         another alternative

Actually, now that I step back a bit, I'm mystified: why is it so wrong to
ask for the start-point or end-point of an attribute or namespace location? 
Why can't these functions treat such locations just like text, comment, and
processing instruction locations? That's what range-inside does. In fact, if
someone wanted to write
    start-point(@foo)
they could get around start-point's dislike of attribute locations just by
writing
    start-point(range-inside(@foo))
If the latter expression isn't erroneous, why is the former?

In fact, it seems to me that:
    start-point(range-inside(L)) = start-point(L) for all locations L
would be a useful identity. (Ditto end-point.) Not that you'd have to say so
explicitly; but you could, for instance, define range-inside(L) as the range
from start-point(L) to end-point(L), roughly speaking.

-Michael Dyck

Received on Monday, 18 December 2000 01:23:54 UTC