Re: XPointer considered incomprehensible

* Henry S. Thompson wrote:
>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.

That seems a creative interpretation of the specifications. A fragment
identifier identifies either one secondary resource or it is undefined
what it identifies; in contrast, the XPointer framework explicitly re-
fers to "one or more subresources". The conceptual model then also be-
comes rather silly; a pointer identifies a secondary resource; a pro-
cessor takes the pointer and a document and produces an identification
of a secondary resource. For error free supported pointers that's just

  char* xpointer_processor(char* pointer, doc) { return pointer; }

As it stands, I have no idea what the XPointer processing model might
be.

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

I think you mean "rewrite the specifications from scratch".

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

Yes, you can also read the text that way, that is the problem.
I note that this is further explained by

  For example, the following pointer part identifies the element
  with an ID (as defined in XPointer Framework) of "intro":

    element(intro)

If this pointer actually identifies said element, then the absence
of said element in the resource does not cause the pointer to cease
identifying a secondary resource, which would contradict what you
say above.

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

Then how do I know whether a pointer identifies a secondary resource?
The documentation of a scheme is not required to specify when a given
pointer part identifies a secondary resource, so scheme documentations
won't do that in the general case, and so there need to be other means
to determine whether they identify such a thing.

To give an example, if a #xpath2(...) pointer evaluates to an empty
node set, is the empty node set a secondary resource? I sure hope so,
but then it's a bit difficult to understand why element() identifies
no secondary resource just because the element referred to is absent.

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

Now that argument is just silly. You could simply require that the
description of a scheme is part of some standard published by a
recognized standards organisation, that would substantially raise
the amount of quality assurance at no, or in fact less, cost for the
Team. Where proprietary schemes are desired, and use of namespaces
is not, you could easily make a vnd.name naming scheme and reserve
names without a . for standards. Quite frankly, the flaws of the
xpath2 scheme, and in fact a number of others, are obvious at a
first reading, if reading proposed registrations is asking too much,
the whole 'review' part of the process is a farce.
-- 
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 Sunday, 3 September 2006 01:35:53 UTC