Comments on XPointer 1.0 CR

From: Kay Michael (
Date: Thu, Jun 08 2000

  • Next message: John Boyer: "XML Base and XPath absolutizing of URIs"

    Message-ID: <>
    From: Kay Michael <>
    To: "''" <>
    Date: Thu, 8 Jun 2000 14:56:46 +0100 
    Subject: Comments on XPointer 1.0 CR
    1. Section 3.4: It would be better to use the same style of language as in
    section 3.3: "Specifications conform to XPointer if they permit URI
    references with fragment identifiers in relation to resources ... and if
    they use XPointer syntax and semantics for the fragment identifier.".
    Reason: W3C has no authority to "require" specifications to conform.
    2. Section 4.2: The syntax of ChildSeq suggests that XPointer is constrained
    to operate on well-formed XML documents (those with a single top-level
    element), in contrast to XPath which also operates on well-balanced XML
    fragments. It might be worth stating this explicitly.
    3. Section 5. The start of this section is rather confusing. It starts by
    saying that XPointer adds two new location types to XPath; but XPath does
    not have the concept of location types, it is a generalisation introduced by
    XPointer. It would almost be possible to fix this by reversing the order of
    the first two bullet points.
    4. Section 5.2, bullets 4 and 5. This appears to ban applications from
    defining a way of binding variables and functions and using them in an
    XPointer, which seems unnecessarily heavy-handed, for example it would make
    it difficult to extend XSLT to use XPointer. Wouldn't it be better to say
    that the set of variable bindings is determined by the application, and is
    empty by default?
    5. Section 5.2, bullet 6. This probably ought to say something about the
    default namespace, rather than leaving it implicit. Again, it seems
    heavy-handed to prevent namespaces being bound in some application-defined
    way, for example in an API that uses XPointer syntax this would make it very
    difficult to refer to namespace-qualified names.
    6. Section 5.3.1. The definition of the axes of a point location should
    include a definition of the parent and self axes. (It perhaps needs to be
    stated that the concept of an axis is *not* being generalized to return any
    location, it still always returns a node-set).
    7. Section 5.3.2, first paragraph. This uses the concept of "document
    order", it would be helpful to include a forwards reference to section
    8. Section 5.3.2, second paragraph. The concept of two points being "equal"
    has not been defined. (It needs to be distinguished from the XPath "="
    9. Section 5.4.1, Note. This extension to XPath syntax needs much more
    formal treatment. Exactly how is the BNF modified? Which functions are
    allowed after a "/"? What are the semantics? I'm worried that this extension
    is "jumping the gun" in terms of how XPath evolves. I think that this kind
    of requirement, along with many others, would be much better met by allowing
    a function to take an expression (or function) as an argument, so it could
    be written say range-to(id("chap1"), function: following::REVEND(1]). (This
    concept is needed to do things such as universal and existential
    quantifiers, summing an arbitrary expression, etc).
    10. Section 5.4.2 second paragraph. This mentions XML normalization of line
    ends. It should also mention normalization of attribute values.
    11. Section 5.4.3 third paragraph. "As defined in XPath" - where in XPath?
    12. Section 5.4.3 fourth paragraph. "the expression fails" - is this concept
    13. Section 5.4.3, function start-point(), fourth bullet. Suggesting this is
    a syntax error implies that it can be detected statically. This is not the
    case, for example start-point((*|@*)[5]): the argument may be an element or
    an attribute node. Same comment applies to end-point().
    14. Section 5.4.6, function unique(), boxed example. I think this should
    read "last()=1". I also feel that this function is gratuitous: if it is
    worth having, it should be in XPath and not in XPointer.
    15. Section 5.4.6, paragraphs from "Note that different" to the end. This
    text seems irrelevant to the section that it forms part of.
    Michael Kay