Re: Xpointer Questions

daniel@w3.org wrote:
> 
>  The XML Linking Working Group reviewed your comments [1] on the
> XPointer second Last Call working draft [2]. They were added to
> the Issue List as Issue XP110 to XP131 [3].
>  We would first like to thank you for a very complete review of
> our specification, it took a long time to process them.
> ... 
> We think your comments will allow to significantly improve the final
> version of the XPointer specification !

Great! I'm glad you think so. That's the whole idea.

> Thanks a lot for your feedback, we would appreciate if you could
> express if the resolution of those issues fits your expectations.

Okay, here are my responses to your resolutions.

----------------------------------------------------------------------------
editorial-dyck/1
'Rejected, the working group did not reach consensus on splitting the
specification, largely because the perceived cost of such a major structural
change late in the process would outweight the benefits.'
    Yes, perhaps. We may not know until (if) someone tries to define another
    scheme.

----------------------------------------------------------------------------
editorial-dyck/2
'Rejected keep the terminology as is, Eve made an analysis and it seems we
use XPointer uniformly in the spec to mean the full interpretation of
XPointer.'
    I disagree. In general, when you describe XPointer as an extension of
    XPath, you're talking about the XPtrExpr sense of XPointer. For example:
        Intro para 4
        Sect 4 para 1
        Sect 5
        Sect 5.1 para 3
        Sect 5.2
        various other places in section 5.
    This usage is a problem when you state restrictions on "XPointers" that
    really only apply to XPtrExprs. In the future, when someone tries to
    define a new scheme, the current wording of these restrictions will
    appear to apply to the new scheme, when it shouldn't.

----------------------------------------------------------------------------
xp111-1-dyck
'Rejected, we were chartered only to define a fragment identifier syntax,
the wording in section 5.2 were for completeness only.'
    That bit about "completeness" doesn't make sense. Completeness of what?
    If that's all you were chartered to do, and that's all that the spec
    does, then "completeness" ends there.  Or to put it another way, if you
    need that wording for completeness in 5.2, why don't you need similar
    wording elsewhere? (I've indicated some of those places in other
    comments.)

    If you really want to take a hands-off position on the use of XPointers
    other than as fragment identifiers of URIs, then you should say so
    explicitly in the Introduction, and then never mention it again.
    Otherwise, people are going to be confused like I was.

    (Personally, I don't see the harm in wording the spec so that it applies
    equally well to XPointers in non-URI contexts, but I guess I can accept
    your reluctance to do so.)

    (Is your charter on-line somewhere?)

----------------------------------------------------------------------------
xp113-1-dyck
'Accepted, add the definition of an XPointer-processor but add the fact that
it is fully conformant.'
    Not sure what the last phrase means. An XPointer-processor that is only
    minimally conforming isn't an XPointer-processor? Then what is it?

    By the way, there are a few occurrences of the phrase "XPointer
    application[s]" elsewhere in the spec; it's probably appropriate to
    change them to "XPointer-processor[s]".

----------------------------------------------------------------------------
xp114-k-dyck
'Accepted, use "replace" since that's what is used in the XML-1.0
specification'
    I think "replaced" is about as bad as "removed". The XML 1.0 spec also
    uses the term "expanded", which I think would be better in this context.

----------------------------------------------------------------------------
xp116-c-dyck
'Rejected, we prefer to keep as is, we need to be able to point at 2
specific productions defined by this specification and prefer to minimize
changes to the productions at this point.'
    Why do you need to be able to point at 2 specific productions?

----------------------------------------------------------------------------
xp113-2-dyck
'Rejected, we don't see it as a point of confusion since it describes an
abstract model.'
    The abstract model is unnecessarily concrete then. You could just say
    "evaluating XPointer parts with schemes that it understands", which
    avoids the (relatively concrete) terms "routing" and "application", and
    which also fits in better with the subsequent clause (about skipping
    unknown schemes).

----------------------------------------------------------------------------
xp113-3-dyck
'Rejected, this is a divergence in interpretation of what is an XPointer
processor, it must understand the xptr scheme'
    Okay, but I made my comment *before* you made that decision about the
    meaning of "XPointer-processor", so it's hardly fair to interpret my
    comment that way. Just replace "XPointer-processor" with "application" 
    and you'll get a comment that should still be valid.

----------------------------------------------------------------------------
xp114-e-dyck
'Accepted, add a single sentence in the paragraph before 4.1.2 "an XPointer
can occur in many other contexts and these will generally have their own
escaping requirements."'
    That addresses my first point, but not the other two.

----------------------------------------------------------------------------
xp114-h-dyck
'Rejected, this section was designed closely with the I18N working groups
and is used as reference in other specs, we prefer not to change it at this
point.'
    This is the first time that the section has been published, and you're
    already closed to public comment about it? That's not very open.

----------------------------------------------------------------------------
xp116-g-dyck
'Rejected, we prefer to keep as is, escaping all parenthesis in general is
not possible, they are needed for scheme boundary detection, only paranteses
within string values may need to be escaped in practice.'
    What I meant (or should have meant) was:
        Software that generates <i>XPtrExprs or SchemeSpecificExprs</i>
        might find it easier to escape all parentheses rather
        than figure out which ones are unbalanced.

    Yes, in practice, only parentheses in string literals need to be
    escaped, but
    (a) not all of them, just the ones that are unbalanced; and
    (b) not just unbalanced within the literal, but over the whole XPtrExpr
        or SchemeSpecificExpr.
    That is, you're saying that
        some-scheme(foo("("),bar(")"))
    doesn't need any paren-escaping, even though the parens-in-strings are
    unbalanced within their individual strings. And you're saying that
        some-scheme(foo("^("),bar("^)"))
    must raise a syntax error.

----------------------------------------------------------------------------
xp117-k-dyck
'Rejected, The left-to-right nature of evaluation means that the later
syntax error in his example wouldn't be caught. Does the existing wording
need to be changed, though? We decided that it's redundant, but not false,
so we're going to keep it.'
    I'm not sure what you're including in "the existing wording", but
    section 3.4 and 4.3 are definitely in disagreement. Section 3.4 says
    that a syntax error must be detected before evaluation (in order to
    prevent evaluation), whereas section 4.3 says that can be detected
    *during* evaluation, and in fact need not be detected at all if
    evaluation doesn't get that far.

    I think you could actually drop section 3.4, and instead rely on section
    4.3 to more accurately and appropriately define the circumstances that
    give rise to the different classes of XPointer errors.

----------------------------------------------------------------------------
xp121-a-dyck
'Rejected, this is Michael Notes on a point which is not directly part of
our specification, keep as is'
    (Huh? Looks like a cut-and-paste error in the statement of your
    resolution.  But I get the drift.) True, it's only a Note, and it's
    talking about DOM, for which this spec is obviously not normative, but
    that's no excuse to use incorrect terminology.

----------------------------------------------------------------------------
xp126-b-dyck
'Rejected, this wording was the result of a lot of discussions during the
first Last Call and CR stage, ...'
    Yes, I participated in that discussion. Regarding my contention that
    FunctionCall semantics are adequate and appropriate for invocations of
    the 'range-to' function, I first raised this on September 8th, in my
    comments on the CR [1].  I highlighted the phrase:
        "found by evaluating the expression argument with respect to
        that context location"
    and said:
        "This is redundant, given XPath's semantics of FunctionCall.
        You could maybe relegate it to a note."
    It seems this didn't make it to the CR issues list. (It would have
    appeared as part of XP95 (MD10) [2].)

    However, I raised the point again on Sept 17 [3]:
        "Presumably you want such a use of "range-to" to have the
        semantics of an XPath FunctionCall..."

    Daniel Veillard replied on Oct 3 [4]:
        "I would rather not associate this range-to construct with a
        conction call [sic]. This is a completely different beast at
        the semantic level"

    I replied the same day [5]:
        "I disagree. It evaluates its argument in the current context
        and yields a result. How is that semantically different from a
        function [call]?"

    Daniel Veillard replied the next day [6], but did not respond to that
    point.

    On Dec 11 [7], while defending the comment that had become XP95/MD10,
    I once again raised the point that FunctionCall semantics suffice,
    and also the point that the phrase
        "For each location in the context"
    is misleading.

    Four days later, after another exchange, Daniel Veillard said [8]:
        "Okay, thanks for your detailed explanations. The
        Working Group ended-up reversing the decision, this
        will be changed in the next version of the draft!"

    As far as I knew, the matter had been settled to my satisfaction, but
    then the current draft came out, with the contentious wording still
    there.

[1]<http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0147.html>
[2]<http://www.w3.org/XML/2000/12/LinkingIssueList.html#XP95>
[3]<http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0166.html>
[4]<http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0001.html>
[5]<http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0002.html>
[6]<http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000OctDec/0004.html>
[7] email:
    To: Daniel.Veillard@w3.org
    CC: w3c-xml-linking-wg@w3.org
    From: MichaelDyck@home.com
    Date: Mon, 11 Dec 2000 23:15:00 -0800
    Subject: Re: ACTION: on MD10 resolution

[8] email:
    To: MichaelDyck@home.com
    From: Daniel.Veillard@w3.org
    CC: w3c-xml-linking-wg@w3.org
    Date: Fri, 15 Dec 2000 10:38:23 +0100
    Subject: Re: ACTION: on MD10 resolution

'the wording suggested potentially change the semantic of the existing
definition, keep as is.'
    Well, this is an interesting claim. If you have an example use of the
    range-to function for which the two wordings produce different results,
    please post it, and we can debate which is the correct result. (My
    belief is that no such example exists; the two wordings describe the
    same intended behaviour. The difference being that my wording is
    consistent with standard XPath FunctionCall semantics.)

----------------------------------------------------------------------------
xp129-d-dyck
'Rejected, keep as is we would prefer to not add complexity at this point'
    Complexity? The following change would satisfy me:
        In the description for each of start-point() and end-point(),
        delete the bullet regarding attribute or namespace,
        and in the previous bullet, change
           "text, comment, or processing instruction"
        to
           "text, attribute, namespace, comment, or processing instruction".
    Can you honestly say that this adds complexity? To my thinking, the
    result is simpler than the current definition. Moreover, I'd say it's
    easier to implement.

----------------------------------------------------------------------------
xp131-a-dyck
'Rejected, this is an old issue already discussed, keep as is.'
    Okay, so where is the data model of an external parsed entity defined?

----------------------------------------------------------------------------

-Michael Dyck

Received on Sunday, 13 May 2001 17:40:49 UTC