Lists Home |
Date Index |
> Date: Tue, 29 Oct 2002 15:04:06 -0800
> From: "Roy T. Fielding" <firstname.lastname@example.org>
> To: email@example.com
> Message-Id: <B98A3692-EB92-11D6-B45Cfirstname.lastname@example.org>
> Subject: XPointer
> I made the mistake of reading this specification today. Allow me to list
> the faults:
> 1) uses probably the most difficult syntax to parse of all options:
> balanced quotes inside balanced parens with encapsulated functions
> and concatenated schemes;
These are not real difficulties for anyone using appropriate tools to
generate lexers and parsers.
> 2) frequent use of characters that are explicitly disallowed
> in the URI syntax and thus must be escaped;
This makes the assumption that XPointers only reside in URIs. While URIs
probably cover a significant number of use cases for XPointer, they are by
no means an overwhelming majority. There are a large number of use cases
where XPointer parts can exist outside of a URI. The number of restricted
characters in URI syntax is more of a problem with the definition of a URI,
rather than with XPointer. Also, as XML uses Unicode as its native
encoding, the ability to select on text content [see #4] will REQUIRE the
use of URI escaping for some class of pointers.
Lastly, most working code today [IMHO] uses the translated text of URIs, not
the escaped text. The URI itself as a byte stream limits what octets can
appear in the URI. However, it not nearly so restrictive as to what
characters can occur. Octets are not equal to characters.
> 3) calls itself a "scheme" and encourages the naming of new "schemes"
> for fragment syntax, in spite of the fact that the URI syntax
> already has something called a scheme; (doesn't anyone have a
The two schemes are in different domains of use. I haven't found anyone yet
confused by the name.
> 4) focuses on mechanical identification of XML elements (fragile
> and media-type-specific) rather than the content (section heading,
> paragraph number, paragraph text, etc.).
Arguably, the author hasn't written many XPath or XPointer expressions.
Most of the ones that I write use content based selection criteria [i.e.,
section heading, paragraph number, et cetera]. In fact, nowhere in XPointer
do I see any focus on either mechanics or content. Instead, there is an
expressive language that supports either mechanical or content based
selection. This is appropriate, considering that the domain of linking and
annotation requires both for different use cases.
> In short, these things are not suitable for use with URIs and should
> not be recommended by the W3C.
> Roy T. Fielding, Chief Scientist, Day Software
> (email@example.com) <http://www.day.com/>
> Co-founder, The Apache Software Foundation
> (firstname.lastname@example.org) <http://www.apache.org/>