Lists Home |
Date Index |
From: "David G. Durand" <email@example.com>
> I am writing to urge immediate action related to Xpointer, if you
> care about it.
> Xpointer seems to be under imminent threat of being gutted. There
> appears to be a significant chance that there will be no XPointer at
> all, or only a drastically cut down one. Particularly endangered are
> the ability to have ranges of any kind, or any forms of addressing
> other than "bare names" or maybe child sequence locations.
Good. XPointer with ranges deserves to die. The last I saw of the
gutting proposals, ranges were being kept, so gutting it will do nothing
to improve its acceptability. The wrong bit is being removed.
Almost everyone who says "I have implemented part of XPointer" seems
to then say "except for ranges" because, compared to most of XPointer,
ranges sit unhappily on the other side of an enormous architectural gap
which should form the natural boundary for separate specs.
The gap is "can I retrieve a WF object which is the subject of
The WWW has succeeded not because URIs give us the ability
to abstractly identify any resource (which is not a bad thing) but because
the resources could be downloaded. The bits before the ":" are
the key to the success of URLs, not the bits after.
The "semantic web" is a nice, but things like ranges should only come
after the practical foundation of the "pragmatic web" based on
In fact, it seems that URIs have succeeded either when they do
have a locatable entity, or when they are their own resource
(such as a uuid). When they are just symbols for things that
have no entity or response from dereferencing them, they
don't seem to have thrived yet. Now ranges may be a way
to allow improvement in that, but the Linking WG should complete the
outhouse first before installing a gold toilet seat.
Small is Beautiful. E.F.Schumaker