- From: Ron Daniel <rdaniel@taxonomystrategies.com>
- Date: Tue, 15 Oct 2002 21:53:04 -0700
- To: <jmdyck@ibiblio.org>
- Cc: <w3c-xml-linking-wg@w3.org>, <www-xml-linking-comments@w3.org>
Hi Michael,
Thank you for your comments on the XPointer Framework Last Call draft,
which are archived at:
http://lists.w3.org/Archives/Public/www-xml-linking-comments/2002JulSep/
0039.html
The XML Linking Working Group has collected all the comments
on the documents and decided what changes to make to the draft.
The dispositions of your comments are given below. Please reply
to www-xml-linking-comments@w3.org within one week if you wish
to make a formal objection to these decisions.
> XPointer Framework
> W3C Working Draft 10 July 2002
>
> 1.2 Terminology
>
> Definition: error
> "results are undefined"
> Not entirely. In fact, for the XPointer processor, the results
are
> quite well-defined: section 2 states that the processor must
report
> the error to the application. Beyond that, yes, results are
> undefined.
>
> Definition: failure
> "failure of a pointer part"
> This phrase isn't really defined. An XPointer processor
identifies
> a subresource of a resource by applying a pointer to it. The
first
> sentence of the definition says that if it's unable to do so,
that's
> a failure. (A failure of the pointer, one might say.) So the
phrase
> "failure of a pointer part" has not been defined.
>
> I think it would be clearer to make "failure" a property (or
result)
> *only* of pointer parts. E.g., change
> The inability of an XPointer processor to identify ...
> to
> The inability of an XPointer processor,
> when evaluating a pointer part of a scheme-based pointer,
> to identify ...
>
> Moreover, you could replace the term "failure" with "pointer
part
> failure". And you could note that the term is typically invoked
with
> wording such as "the pointer part fails".
>
> Yes, this would mean that you can no longer talk about "the
failure
> of a shorthand pointer", but there seems to be no need to. Where
> section 3.2 says:
> If no element is identified by this process, the Name fails
and
> the pointer is in error.
> just delete:
> the Name fails and
> and you've lost no semantics.
The material on 'failure' and 'error' has been modified along the
lines suggested.
>
> Definition: namespace binding context
> "A list of ... pairs of ... prefixes and ... URIs."
> This description doesn't disallow a list that contains multiple
> pairs with the same prefix. It would probably be better to use
> XPath's terminology: a *mapping* from prefixes to URIs.
>
> And actually, it's URI references, not URIs.
Done (namespace binding context, s/list/mapping/ and reword)
> ----------------------------------------------------------------------
> 2 Conformance
>
> para 2 + 3
> "normatively depend on"
> It's not entirely clear what this means. I understand what it
means
> for a specification to normatively depend on another
specification,
> but this is talking about XPointer processors normatively
depending
> on certain procedures and information to do with the input that
the
> application passes to it. Thus, this seems to be more about the
> conformance of the application than the XPointer processor.
Done (s/normatively depends on/depends on/)
> para 3
> "sufficient input about an XML resource to identify the following
> information items and properties"
> Isn't the infoset part of the resource? In which case, you
shouldn't
> need additional input about the resource. (And if the infoset
isn't
> part of the resource, what is?)
Done ("XPointer processors depend on the ability of applications to
expose an XML resource as at least the following information items
and properties, in the cases where they exist in the resource:")
> ----------------------------------------------------------------------
> --
> 3 Language and Processing
>
> para 2
> "a fragment identifier taken from the URI reference that was used to
> access the resource"
> It seems unnecessary to *require* that the XPointer processor's
> input be derived from a URI reference. Yes, that's the expected
> case, and the case that the XPointer language is explicitly
intended
> for, but it doesn't have to be the only case allowed. It's not
like
> the XPointer processor cares where its input comes from.
>
> Instead of the quoted phrase, you could say
> a string to be used as a pointer
> which nicely parallels the phrasing in 3.1 para 1.
Done. Added the commenters requested text, moving our text into
an "e.g" clause, to get the best of both worlds.
> "the pointer extracted from the fragment identifier"
> It's never stated what this extraction entails. I'm not sure
that
> it entails anything.
No action seems necessary here.
> "the XPointer processor must reverse the encoding"
> This appears to be at odds with section 2 para 2, which I took
to
> imply that the application must reverse the encoding.
>
> Note that, if you accept that a XPointer processor's inputs
might
> come from somewhere other than a URI reference, only the
application
> will know whether any 2396/2732-decoding is necessary.
Fixed by some rewording
> ----------------------------------------------------------------------
> 3.1 Syntax
>
> XPointer Framework Syntax
> [3] schemebased ::= ptrpart (S?, ptrpart)*
> Delete the comma.
Done
> Validity constraint
> "The end of a pointer part is signaled by the right parenthesis ")"
> character that is balanced with the left parenthesis "(" character
> that began the part."
> This sentence sounds more like a parsing rule than a syntax
rule.
> Does it express a constraint, or is it just a preamble to the
real
> constraint?
>
> "If either a left or a right parenthesis occurs without being balanced
> by its counterpart"
> This wording suggests that a parenthesis could have a
counterpart
> and yet not be balanced by it. I suggest:
> ... without being balanced by a counterpart
> or
> ... without having a balancing counterpart
> or
> ... without having a counterpart to balance it
>
>
> "Any other use of a circumflex is an error."
> So escaping *balanced* parentheses is an error? I think this is
a
> bad idea. For instance, consider the ptrpart:
> some-scheme(blah(")("))
> The person who writes it may think, "Well, the parentheses in
> blah(...)
> are certainly balanced, but the parentheses in the string
literal
> ")("
> aren't, so I'd better circumflex-escape them." Thus:
> some-scheme(blah("^)^("))
> However, from the XPointer processor's point of view, the
schemedata
> blah(")(")
> *does* have balanced parentheses. So the version with
circumflexes
> is supposedly an error? This seems unnecessarily restrictive.
>
> You could avoid all these problems by dropping the validity constraint
> and instead specifying the constraint in EBNF:
> [6] schemedata ::=
> ( Char - [()^] | '^(' | '^)' | '^^' | '(' schemedata ')' )*
The material on balancing and escaping parens and circumflexes
has been updated along the lines suggested.
> ----------------------------------------------------------------------
> 3.2 Shorthand Pointer
>
> para 1
> "an XML-defined Name"
> This could be misunderstood to mean something like "a name that
has
> been defined by an XML document somewhere", rather than "a token
> that matches the 'Name' symbol defined in the XML
specification".
> I think it would be much clearer to say, in the Syntax section:
> The symbols 'Name', 'S', and 'Char' are defined in the XML
spec.
> The symbol 'NCName' is defined in the XML Namespaces spec.
Done.
> point 1 and 2
> "with an [attributes] collection containing an attribute II, or whose
> [children] collection contains an element II"
> This might be a bit clearer if the two clauses had parallel
> structure:
> whose [attributes] collection contains an attribute II, or
> whose [children] collection contains an element II
This section is being reworked for clarity.
> last para before the Note
> "the Name fails and"
> Delete. (See my comment on the definition of failure.)
Done.
> ----------------------------------------------------------------------
> 3.3 Scheme-Based Pointer
>
> para 1
> "XML-defined white space"
> "XML-defined Char"
> See my comment on 3.2 para 1.
Done.
> para 2
> "In the case of URI references referring to any resource"
> I don't think it's necessary to bring up URI references here.
You
> could replace the quoted phrase with just:
> For any resource
Changed during other edits.
> "this specification reserves all scheme names ..."
> Could you be more concrete about what this means?
>
> One possibility is that a conforming XPointer processor must
(for
> these media types) treat any scheme name other than those
defined by
> W3C XPointer scheme specs as an error. However, this would be
rather
> impolite, given that you're encouraging other XML-based media
types
> to use the XPointer framework in defining their own fragment
> identifier languages: consider what happens when such a language
is
> *not* defined by a "W3C XPointer scheme specification", and
content
> negotiation causes the resource to be represented as text/xml,
> rather than its usual text/something+xml. Suddenly the fragment
> identifier doesn't work, even if it includes an xpointer()
> fallback.
>
> Instead, perhaps the XPointer processor must treat it as a
failure
> of the pointer part. If that's the case, it would make more
sense to
> say it *after* the subsequent paragraph, which talks about
> evaluating pointer parts.
Extensibility of scheme names has been updated. Basic idea is
for scheme names to be QNames. Unprefixed QNames are reserved
for W3C Recommendations.
> para 3
> "the scheme identifies no subresource"
> Change "scheme" to "scheme data", I think.
Done
> "that part is consumed"
> "Consumed"? An XPointer processor consumes pointer parts?
> How about "that part is skipped"?
Done.
> "If a scheme-based pointer has an error in its construction as a
> whole, evaluation stops and pointer parts are not consumed."
> Shouldn't the XPointer processor detect 'an error in the
> construction as a whole' before starting evaluation?
>
> Anyway, section 3.1 para 1 says: "If a string used as a pointer
does
> not adhere to the syntax defined in this section, it is an
error."
> Doesn't that cover this?
>
> If it does, delete this sentence: section 3.1 para 1 is clearer.
>
> If it doesn't, please clarify this sentence.
Changed during cleanup of material around 'failure' and 'error'.
> para 4
> "A scheme-based pointer might contain characters that are not allowed
> in a URI reference."
> This is true of shorthand pointers as well, so this paragraph
> probably belongs in section 3.1.
Done. Moved escaping section up in the hierarchy.
> "by the time a pointer is fed as input ... into a URI resolver"
> Unless a URI resolver resolves URI references (not just URIs),
it
> won't see fragment identifers.
Done. s/URI resolver/URI reference resolver/
> ----------------------------------------------------------------------
> 3.4 Namespace Binding Context
>
> para 1
> "interpreting element and attribute names' namespace prefixes"
> This might be clearer as "interpreting the namespace prefixes
> of element and attribute names".
Done. s/interpreting element and attribute names' namespace prefixes/
interpreting the namespace prefixes of element and attribute names/
> para 2
> "Pointer parts must not attempt to redefine the 'xml' prefix"
> Given the "must not", wouldn't the attempt be a violation of the
> framework? In which case, I'd expect at least a pointer part
> failure, if not an error. Or do you only mean "should not"?
>
> And if a pointer part binds 'xml' to its proper URI, does that
> constitute "redefining" it?
Rewritten for clarity.
Best regards,
Ron Daniel Jr.
Acting chair, XML Linking Working Group.
Tel: +1 925 368 8371
rdaniel@taxonomystrategies.com
Received on Wednesday, 16 October 2002 00:53:08 UTC