XPointer subset minority opinion

Regarding the decision taken by the Linking WG on 19 April 2001 not
to subset XPointer:

The undersigned believe that XPointer would benefit from offering the
option of a much more modest feature set, along the lines of our
FIXptr proposal, that accords with the deployment and implementation
patterns seen to date.

XPointer's feature set started fairly large (its TEI-derived axes were
eventually to contribute to XPath), and it has only grown larger in
recent years (including "schemes"; points; and conformance levels added
solely for the convenience of "*+xml" media types over which XPointer
has no control). If all the features had been added as an outgrowth of
specific user demand and were well tested in the field by this point,
four-plus years into XPointer's development, they would not present a
problem.  However, this is not the case.

The trend towards larger specifications is not merely inconvenient for
developers; it can hamper implementation attempts, harm
interoperability, and dampen enthusiasm for W3C's work by users and
developers alike.  It may be worth noting that several of the vendors
involved in XPointer's development who are likeliest to be in a
position to deploy it have no concrete plans to do so.

Also, although no speed-of-implementation goal was ever set forth by
the WG, we note that the single known complete implementation of
XPointer took about two weeks, and the four known experimental
implementations of the FIXptr proposal each took about half a day.  Surely
it is significant that getting four implementors to try the proposal on
a casual basis was so easy, compared to the process of uncovering full
XPointer implementations. And it appears that no users of the partial
XPointer implementations today would lose any functionality if they
were limited to FIXptr.

One criticism of the proposal has been that it does not have any native
syntax for ranges, which awkwardly requires the repeating of the URI
portion of the URI reference in whatever non-native range syntax is
chosen, and which makes it appear as if it is unfriendly to the concept
of ranges.  In response, we have slightly revised the proposal to add
range syntax support; see the following link (Member-only):


    http://lists.w3.org/Archives/Member/w3c-archive/2001Apr/att-0134/01-
    NOTE-FIXptr-20010425

It should be mentioned that the lack of a clear XML processing model is
contributing to uncertainty about how to use and deploy XPointer.  Some
believe we should just be patient, get XPointer out there as a
Recommendation, and wait for deployment.  However, a more reasonable
stance would be to offer conformance levels, with the minimal such
level supporting only clear, unambiguous deployment scenarios.  The
FIXptr proposal attempts to address such scenarios.

While recognizing that XPointer subsets have been decisively rejected
several times by this WG, we nonetheless urge W3C to consider FIXptr's
features as a way to provide 80 percent (or more) of users' needs with
20 percent (or less) of XPointer's implementation complexity. One way
to make this happen would be to extend the XPointer shorthand syntax to
include FIXptr and define a conformance level consisting of just the
shorthand.

         Eve Maler, Sun Microsystems
         and
         Paul Grosso, Arbortext
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com

Received on Thursday, 3 May 2001 17:34:50 UTC