Re: XPointer considered incomprehensible

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

Bjoern Hoehrmann writes:

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

That's not how I read it -- for any URI scheme, documentation of a
fragment identifier syntax has to explain _how_ it identifies a
secondary resource.  That's what the XPointer specs. do.  The issue of
discontinuous/multiple secondary resources is a separate matter, on
which I still owe you a reply.

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

This reminds me of tendentious claims that there's nothing wrong with
the phrase "the current king of France is bald" -- it may have a
'meaning' in a formal-logic kind of way, but it's in practice
useless (today).  Just so, element(intro) doesn't identify anything if
there's no such element -- the Framework is clear about that, as far
as I can see.

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

Success/failure of syntactically OK pointer parts to identify is
always an empirical question (just as for element(intro) above).  The
only way to find out if a pointer part identifies a secondary resource
is to pass it to a implementation of the scheme and look at the
result.

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

That question is surely up to the spec. of a scheme to make clear.
Reasonable persons might differ on this one -- seems to me if I were
speccing this one I'd treat an empty node set as failure to identify
a secondary resource.

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

I'll take this suggestion to the Architecture Domain in the Team (note
that the Registry is not the responsibility of the XML Core WG), but I
have to say it's not a direction I personally would like to see us go
- -- at the time XPointer went to REC we were asked, by several Members,
to provide a way to broker contention for scheme names for public use.
The current Registry provides just that.  I understand that you would
like to see it provide more than that, but that involves taking on
responsibility, one way or another, for the quality of the schemes
themselves, and I don't think that makes sense from a cost/benefit
perspective.

ht
- -- 
 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/BF6kjnJixAXWBoRAnVjAJsFkdX2GXMh8qn6d/HbM3K3DcMbQACdEC5F
/itOUzSADbCDvVXUwLYoI2A=
=1PJ8
-----END PGP SIGNATURE-----

Received on Monday, 4 September 2006 11:44:05 UTC