Re: XPointer

>>     2) frequent use of characters that are explicitly disallowed
>>        in the URI syntax and thus must be escaped;
>
> The syntax does use characters that must be escaped according to
> RFC 2396. However, we anticipate that future revisions of 2396
> will allow a much broader character repertoire. That should have
> the knock-on benefit of eliminating much of the escaping
> currently required.

Speaking as the one editing the revision of 2396, I can assure you
that double-quote will not allowed in the URI syntax.  Such a change
wouldn't be even remotely compatible with deployed implementations.

>>     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
>>        thesaurus?)
>
> The XPointer schemes were strongly inspired by URI schemes, for
> the same reason - extensibility. A different name could have been
> chosen, but that would be open to criticism on the grounds that
> terminology for extension schemes was being proliferated needlessly.
>
> The scheme approach has been a public feature of the XPointer
> work since the July 1999 working draft:
>    http://www.w3.org/1999/07/WD-xptr-19990709
>
> Up to now there has been no criticism of the term brought to the
> attention of the working group, nor any complaints of confusion.

Did I forget to mention that I have no respect for the way W3C working
group process isolates standards committees from the people who implement
the technology?  I don't care how the decision was reached -- it is harmful
to use the same term twice within the same context to mean two entirely
different things.

>>     4) focuses on mechanical identification of XML elements (fragile
>>        and media-type-specific) rather than the content
>> (section heading,
>>        paragraph number, paragraph text, etc.).
>
> I'm sorry, can you please clarify? The XPointer work is chartered
> to be media-type specific.

I am well aware of that.  However, URI and fragment identifiers are not
media type specific, and in fact do not allow media type concerns to be
interleaved with identification.

ID is a reasonable solution, but one that existed prior to XPointer.
Other ways of identifying content independent of media type include
search terms, paragraph text, and regular expressions.

>> In short, these things are not suitable for use with URIs and should
>> not be recommended by the W3C.
>
> The problems you have identified do not prevent the
> development of implementations. Nor have they prevented
> others from using the framework to create their own fragment
> identification schemes.

No, it just requires that they be inefficient, ugly, and not useful
to the average user of content that seeks to use fragment identifiers
to identify content.  Of course they can be implemented, but that
doesn't mean they should be recommended.

....Roy

Received on Wednesday, 30 October 2002 19:31:51 UTC