Comments on XPointer last call

Dear XML Linking specialists,

Here are some general last call comments on your XPointer spec:

- The spec should clearly define the expectations with respect
  to management/reservation of schemes (according to 2.3
  of the spec). How can new schemes be defined independently
  without the risk of two scheme taking the same name?
  [Please note that at first sight, it may look as if each
  mime type could define the schemes it accepts, and no global
  registry/conflict avoidance is needed, but this is not true,
  because of content negotiation. Both a type text/abc and
  a type text/xyz may define a scheme foo, in different ways,
  and it would be impossible for an XPointer to contain both
  of them and use the appropriate one based on the content
  type.]

- The spec should make XPointers at least a 'SHOULD', not a 'MAY',
  for specialized media types based on XML. This should be made
  clearer both in the intro and in section 2.3 (e.g.
  change 'may choose to participate' to something like
  'is expected to participate').

- The integration of namespaces and XPointer seems to need
  improvement. In particular, addressing a node by its
  qualified name is much too complicated. I propose to
  replace the syntax:
      local-name()='y' and namespace-uri()='http://www.foo.com/bar'
  by something like
      uri-name()='http://www.foo.com/bar:y'
  where the last colon found in the string serves to distinguish
  between the URI and the name. Other syntactic improvements should
  also be considered, e.g. to be able to replace
      id("intro")//x:para
  with something like
      id("intro")//nuri('http://www.foo.com/bar'):para

- It is rather difficult to figure out how to get a point.
  It looks like the main way is to first get a range with
  string-range(), then get the start with start-point().
  There should be a more direct way to get a point. How
  to get a point or a range should be shortly mentionned
  in sections 3.3.1 and 3.3.2.

- RFC 1738 and RFC 1808 should be removed from references, or
  moved to non-normative. RFC 2396 should be moved to normative.
  [RFC xxxx] is enough as a reference tag, no need for IETF.

- Please start URIs for RFCs with http://www.ietf.org/rfc/...

- References should be streamlined. In particular, '[Geneva]'
  (two times) and 'Brown University. Seekonk:' should be
  removed. For ISO, the URI www.iso.ch should be given.

- A reference to DOM2 is needed, but why a reference for DOM1?

- Overall: It should be 'URI reference' and not 'URI-reference',
  in accordance with RFC 2396. In that document, 'URI reference'
  is used about 25 times, 'URI-reference' is used 4 times, two
  times in a formal place where a space wouldn't have worked.

- 2.1 'The three forms are defined as follows': The list of
  syntax rules that follows does not clearly identify the three
  forms. The text before the rules should say something like:
  The three forms are Full XPointers (represented by 'GeneralFragmentPart+'
  below, see 2.1.1), ...). It would be good to change 'Name'
  in the syntax to 'BareName', and to replace 'GeneralFragmentPart+'
  by FullXPointer and make a new rule
       FullXPointer ::= GeneralFragmentPart+
  There should also be a short descriptive paragraph saying something
  like: If an XPointer consists only of characters allowed in XML
  names, then it's treated as an ID, if it contains slashes
  and numbers, too, then it's a bare name, otherwise it's a
  full XPointer, potentially including some abbreviations.

- [Definition:] node: This has to be rewritten. XPath, and therefore
  XPointer, has text nodes. Infoset does not, it has character
  information items only
  (see http://www.w3.org/TR/xml-infoset#infoitem.character).
  A related problem appears in 2.1.1; there are no CDATA information
  items in the information set, there are only peripheral information
  items for Cdata-start and -end (see e.g.
  http://www.w3.org/TR/xml-infoset#infoitem.start.CDATA).

- A definition for (XPath) position should be added, with some
  text about it's index origin (1).

- Please make sure the final Recommendation will have a
  pointer to errata.

- 2.1.1: documents don't have attributes; elements have them.
  Also, please use lower case for 'name' in accordance with
  XHTML 1.0.

- 2.1.3: Why does /1 address the document element? How are other
  elements on the same level, e.g. PIs before the document element,
  addressed?

- 2.2, validity constraint expr restrictions: 'here' is not clear,
  please clarify.

- Text e.g. of <code> elements appears significantly too small
  both in print and on screen, when compared to the rest of the
  text.

- Intro, third paragraph: 'user traversal', 'browser traversal',...:
  The word 'traversal' is used in a rather fuzzy way; the text
  could be improved to make clearer what it means.

- Intro, 'expression language used in the XSL ...' ->
  'expression language also used ...'

- intro, completeness requirements: 'such as could be': improve wording.
         expressiveness requirements: 'offsets and the like': improve wording.
         robustness requirements: 'for whether they': improve wording.
         general user requirements: add ',' after 'abruptly'.

- intro: 'URL (now URI)': just use 'URI' here. The original RFC 1630
  used URI too, URI is not a new invention.

- intro: TEI, this application: of what? maybe replace with 'this specification'.

- intro, last paragraph before 1.2: especially uses the wrong reference
  (XPointer instead of hypertext systems).

- 1.2, 'in addition, XLink...': This is XPointer; 'following forms' ->
  'following three forms'.

- 1.2, editor's note: As such notes are not supposed to appear in published
  versions, this example should also be removed (and above 'three' changed
  to 'two'). Also, in case an XML version is published, please make sure
  both HTML and XML versions, as well as maybe others, contain the same
  information.

- 1.3, root: The unique tree node of what? 'this is because': improve
  wording.

- 1.3, singleton: Aren't ITEMs in a List contiguous (at least for
  HTML, the LIs are, maybe use a different example)

- 2., 2nd paragraph: 'For example, one may' -> For example, one function may

- 2.1, title: Forms .... of IdentifierS

- 3.3.1: definition of node-point: Change wording so that 'node-point'
  appears earlier on, and that it is clear clear that this is what
  is defined even without boldening the word. Same for other definitions,
  e.g. 'character-point'.

- The XPath Summary in App B is a good idea. I with XPath had
  explained the basics as well as this app does.

- The title and introductory sentence of B.2 should be changed,
  because it is confusing to read 'XPath Axes: XPath's axes are
  summarized in another chapter'.

- In 3.3.2: 'the other point of the range must be the same.':
  The same type? or the same instance?

- In 3.3.2: 'Otherwise, the string-value consists of the characters
  that are in text nodes and that are between the two points.':
  This seems like a highly unprecise definition. Please improve wording.

- 3.3.5 Document Order: 'XPointer extends XPath's concept of document
  order to cover point and range locations.': Please add a link to
  the relevant section of XPath.

- 3.5: 'are treated as a single white-space before for': spurious 'before'.

- B.2: XPointer's range and string axes are NOT defined in a
  later section, but earlier in the spec.

- B.3: locate other nodes relative to each of its nodes in turn:
  'each of its nodes in turn' -> 'this node' (i.e. the context node)

- B.3: Remove ',' before 'therefore'.

- B.3: Remove '[Definition:]'.

- B.3, ancestor-or-self: Because ancestor-or-self is backwards, and
  we want the node closest to the 'ref37' node, shouldn't it be
  'position()=first()' (or whatever does that job) instead of
  'position()=last()'. If last() is correct, please explain why.
  In the same example, shouldn't it be 'attribute::xml:lang'
  instead of 'attribute::lang'?

- B.5: 'All XPath's' -> 'All of XPath's'.

- B.6, child: 'the axis identifier and parentheses to be omitted'
  -> 'the child axis identifier and double colons to be omitted'

- B.6, ancestor: ancestor::*[1] is a bad example, because 
  parent::* would do the job (or wouldn't it?). Maybe make
  a grandparent example.

- It may be a good idea to add a table showing how to get from
  each type of XPointer expression to each other type, with
  references to the relevant function definitions.


Regards,   Martin.


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org

Received on Sunday, 26 December 1999 22:28:35 UTC