W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > July to September 2002

XPointer: comments on Last Call Working Drafts

From: Michael Dyck <michaeldyck@shaw.ca>
Date: Tue, 30 Jul 2002 23:53:13 -0700
To: www-xml-linking-comments@w3.org
Message-id: <3D478959.2080407@shaw.ca>

[Third time I'm sending this. Sorry if anyone is getting multiple copies,
but it's not showing up in the archives.]
------------------------------------------------------------------------
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.

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.

------------------------------------------------------------------------
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.

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?)

------------------------------------------------------------------------
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.

"the pointer extracted from the fragment identifier"
      It's never stated what this extraction entails. I'm not sure that
      it entails anything.

"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.

------------------------------------------------------------------------
3.1 Syntax

XPointer Framework Syntax
[3] schemebased ::= ptrpart (S?, ptrpart)*
      Delete the comma.

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 ')' )*

------------------------------------------------------------------------
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.

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


last para before the Note
"the Name fails and"
      Delete. (See my comment on the definition of failure.)

------------------------------------------------------------------------
3.3 Scheme-Based Pointer

para 1
"XML-defined white space"
"XML-defined Char"
      See my comment on 3.2 para 1.

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

"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.

para 3
"the scheme identifies no subresource"
      Change "scheme" to "scheme data", I think.

"that part is consumed"
      "Consumed"? An XPointer processor consumes pointer parts?
      How about "that part is skipped"?

"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.

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.

"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.

------------------------------------------------------------------------
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".

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?

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XPointer element() Scheme
W3C Working Draft 10 July 2002

1 Introduction

para 3
"The terms ..."
      Actually, the term "application" isn't used at all in this spec.

"Note that errors defined by this specification are distinct from
XPointer Framework errors."
      Well in that case, this spec *doesn't* use the term 'error' as
      defined in the XPointer Framework spec, as claimed by the preceding
      sentence.

      But in fact, this spec doesn't need to use the word 'error'. Where
      it says (section 3 para 2):
          it is an element() scheme error and the pointer part fails
      it could just say:
          the pointer part fails
      with no loss of semantics.


------------------------------------------------------------------------
2 Conformance

para 2
"normatively depend on sufficient input about ..."
      See my comments on Framework section 2 paras 2+3.

------------------------------------------------------------------------
3 Language and Processing

para 2
"it is an element() scheme error and"
      Delete. See my comment on section 1 para 3.

element() Scheme Syntax
[1] elementschemedata ::= (Name, childseq?) | childseq
      Delete comma.

[2] childseq ::= ('/' [1-9] [0-9]* )+
      Delete space before right paren.

para 6 ("A child sequence appearing alone...")
"The integer following the first slash represents the nth"
      Insert 'n' after "integer"?
      Change "represents" to "locates".

"which case"
      Insert "in" before "which".

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XPointer xmlns() Scheme
W3C Working Draft 10 July 2002

1 Introduction

para 3
"The terms ..."
      The term "application" isn't used at all in this spec either.

"Note that errors defined by this specification..."
      Ditto my comment on the same sentence in the element() scheme spec.

------------------------------------------------------------------------
3 Language and Processing

para 2
"it is an xmlns() scheme error and"
      Delete.

para 3
"S is as defined"
      Change "S is" to "S and Char are".

para 4
"(NsURIRef)"
      De-bold.

"and serves"
      Insert "thus" after "and".

"If a pointer part defines a binding for a namespace prefix that already
has an entry in the namespace binding context, the new entry overrides
the old one."
      This sentence should be moved to section 3.4 of the Framework spec.

para 7
"If the pointer part fails due to failure to conform to the syntax
described in this specification, it does not contribute an entry to the
namespace binding context."
      This would be easier to state at the end of para 2: there, change
          the pointer part fails.
      to
          the pointer part fails and does not contribute an entry to the
          namespace binding context.

para 9
"The prefixes used in pointer parts ... the pointer part is addressing"
      You switch from plural to singular.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

-Michael Dyck
Received on Wednesday, 31 July 2002 02:54:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:44 GMT