Next message: John Boyer: "XML Base and XPath absolutizing of URIs"
Message-ID: <93CB64052F94D211BC5D0010A800133101FDEE1E@wwmess3.bra01.icl.co.uk>
From: Kay Michael <Michael.Kay@icl.com>
To: "'www-xml-linking-comments@w3.org'" <www-xml-linking-comments@w3.org>
Cc: w3c-xsl-wg@w3.org
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
5.3.5.
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 "="
operator).
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
defined?
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.
Regards,
Michael Kay