Re: XPointer considered incomprehensible

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bjoern Hoehrmann writes:

> 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 terminology could, with hindsight, have been improved.  What's
meant is what the URI spec. [1] calls a _secondary_ resource.  There
is no requirement that secondary resources be in any straightforward
way subparts of the primary resource identified by the pre-fragment
part of a URI.

I also agree that on the face of it the phrase "XML subresource" is
ambiguous, in that it could be read as per e.g. "big part"
[wrong] or as per e.g. "car part" [right].  That is, "XML subresource"
is short for "subresource of an XML resource", and indeed it only
occurs once, whereas the longer and unambiguous phrase is used
repeatedly.  I also note one use of "subresources _within_ an XML
resource", which is also at best sloppy and at worst wrong.

We should log editorial errata to correct all this, thanks for
pointing it out.

> 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 think this one is OK, in that the Framework is working from the fact
that a single XPointer expression may contain _multiple_ pointer
parts, to enable fallback.  It's only an error if they _all_ fail to
identify a subresource.  Hence for a _single_ pointer part to fail
softly and allow fallback, it should just not identify a subresource.
And that's what the element() scheme prose you quote is doing.

> I note that there are registered XPointer schemes that cannot reasonably
> be considered to identify XML subresources in XML resources.

See above -- subresources need not be XML.

> 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

Not so -- since the SVG Viewer can correctly determine a secondary
resource from the first pointer part, we're done.


> 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

Oops -- my bad.  I had forgotten that requirement when we drew up the
registration policy.  We could perhaps consider

 a) Making it clear that this is a requirement for registration and
 b) Chasing existing non-compliant registrations to get them to
    comply.

but see below about resourcing.

> it then appears that objections to proposed new schemes can only
> cite non-technical arguments, making the whole review process a
> rather silly undertaking.

Well, the primary purpose of registration is not to do QA on XPointer
schemes, but to manage contention for shortnames.  Registration does
_not_ imply blessing by the W3C in any way.

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

Requiring "adequate specification" before registering a scheme amounts
to insisting that scheme documentation go through the W3C process,
which contradicts the purpose of the Registry, namely to allow
XPointer scheme registration from _outside_ the W3C.  The only basis
on which the W3C went ahead with launching the Registry was that it
required a bare minimum of Team resourcing.  Any kind of QA
requirement would require substantial resourcing.  If W3C Members
request this, it can and should go in to the pot to compete with all
the other requests for Team resources, but that hasn't happened so
far as I'm aware.

[I'll return to your comments about external parsed entities and
XPath2 in a later posting -- out of time for today]

ht

[1] http://gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-07.html#fragment
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFE+GMDkjnJixAXWBoRAqDiAKCCYI9DqKjOikDIT+AYQwv1YPBeWACfQZWO
CqjFTm/m1nRyHoSEnqpn07A=
=2ogC
-----END PGP SIGNATURE-----

Received on Friday, 1 September 2006 16:43:14 UTC