XPointer considered incomprehensible

Dear XML Core Working Group,

  I read the three XPointer Recommendations and the XPointer Registry
policy and was unable to make much sense out of them. The documents are:

  [1] http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
  [2] http://www.w3.org/TR/2003/REC-xptr-element-20030325/
  [3] http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/
  [4] http://www.w3.org/2005/04/xpointer-policy.html

The first problem is that the XPointer Framework relies heavily on the
concept of "subresources", or more specifically, XML subresource con-
tained within XML resources. None of the documents makes any attempt to
define this term, and the term is used in contradictory ways; an example
is the following contradiction.

The XPointer Framework specifies that "If no pointer part identifies
subresources, it is an error"; in contrast, for the element() scheme it
is specified that "... except that failure to identify an element
results simply in no subresource being identified by this pointer part
rather than an XPointer Framework error." There is no provision in the
Framework specification that individual schemes can override core
aspects of the Framework, which implies that one of the specifications
is in error. It is unclear to me which specification.

I note that there are registered XPointer schemes that cannot reasonably
be considered to identify XML subresources in XML resources. An example
is the svgView scheme originally defined in the SVG 1.1 Recommendation.
It is entirely unclear how such a scheme fits into the XPointer Frame-
work, the very definition of "XPointer processor" is "A software
component that identifies subresources of an XML resource by applying a
pointer to it." An implementation of only the 'svgView' scheme does not
do that in any way, which implies it is not an XPointer processor. What,
then, is it, and why is 'svgView' still an XPointer scheme?

We can take this one step further and construct the following resource
identifier:

  http://example.org/example.svg#svgView(scale(0.5))element(foo)

Considering a software module that is both an SVG Viewer and a XPointer
processor, it is unclear to me how this resource identifier is to be
processed, and which specification would be responsible to define this.
According to the XPointer Framework, the svgView scheme must be ignored
and the fragment identifier identifies the element with id 'foo'. Like-
wise, if we have

  http://example.org/example.svg#svgView(scale(0.5))

The svgView part must be ignored, and as no subresource is identified,
the XPointer processor will report an error. It therefore appears to be
impossible to construct a software module that conforms to both XPointer
and SVG, making these two specifications genuinely incompatible.

The next problem is that it is, as seen above, entirely unclear what re-
quirements new XPointer schemes must meet. The implied requirement, that
the scheme identifies "subresources", is obviously ridiculous, and there
is only one explicit requirement in the Framework specification, namely
"The documentation for every scheme must specify whether it uses the
namespace binding context." The registration policy does not cite this
requirement and schemes that fail to meet this requirement have been
registered in the past, it then appears that objections to proposed new
schemes can only cite non-technical arguments, making the whole review
process a rather silly undertaking.

Silly in particular because this will inevitably cause a situation where
important names are taken for schemes that lack adequate specifications,
indeed, in addition to the problem mentioned above, a broad range of
schemes with only unstable draft documentation has already been
registered.

I note that the lack of requirements include syntactic requirements, it
is unclear what to make of the specification in the light of the 1.1
versions of XML and Namespaces in XML, combined with the lack of error
handling requirements for syntax errors, and the complete lack of up
to date discussion on how to name new schemes.

The next problem is a core claim of the framework that it can be applied
to external parsed entities. The framework specification fails to make
any reasonable effort in defining how this is supposed to work, it says,
as an aside,

  Note that if the XML resource is not a document but rather an external
  parsed entity, this property will not be reported. Rather, the
  information set is effectively extended to report the one or more
  top-level elements in the entity as ordered "root element" properties
  for the entity.

It is entirely unclear what to make of this; considering an external
parsed entity like http://example.net/example.ent

  <?xml version="1.0"?>
  Hello
  <foo:bar/>
  World
  <foo:bar/>
  !
  <!-- EOF -->

There is no way to know what the "extended Infoset" might look like, the
XML Infoset Recommendation does not apply to external parsed entities
and the informal text cited above does not say anything about handling
the lack of namespace declarations, white space, or how to construct the
'children' property of the Document Information Item. I even fail to see
how the addition of '"root element" properties' makes any sense here.

If we now consider http://example.net/example.ent#xpath2(...) where the
entire specification of the xpath2 scheme is given as

  Locates a node or node set within an XML Information Set. The
  single argument is an XPath path as defined in the W3C XPath 2
  Recommendation. The node or node set resulting from evaluating
  the XPath is the reference. Note that in some contexts it is
  an error if a node set (rather than a single node) is returned.

I do not understand the first sentence for I do not know whether it
refers to the Infoset as defined in the Infoset specification, or the
incomprehensibly extended Infoset as explained above. In case of the
latter, I have no idea how to construct the XPath data model for the
example external parsed entity given above. The second sentence does
not make sense either, there is no W3C XPath 2 Recommendation, and I
am not sure whether this refers to a PathExpr or a Expr, or something
else, as defined in the XPath 2.0 CR. The last sentence is gibberish.
Worse, there is no way of knowing how to process e.g.

  http://example.net/example.ent#xpath2(document(...)/*)

or

  http://example.net/example.ent#xpath2(fn:doc(...)/*)

or even

  http://example.net/example.ent#xmlns(x=urn:example)xpath2(//x:y)

because, contrary to the requirements for pointer documentations,
there is no discussion of the namespace binding context, or in case
of the first example, any discussion of the exact processing model.

There are several more issues here, but considering how the XML Core
Working Group usually handles my comments it does not make much sense
to write those up at this point. The XPointer specifications and the
registry are too broken to derive any practical benefit from them
anyway.

regards,
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 1 September 2006 16:52:15 UTC