W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > October to December 2002

Re: REJECT: XPointer PR

From: Daniel Veillard <daniel@veillard.com>
Date: Thu, 14 Nov 2002 10:01:35 +0100
To: "Simon St.Laurent" <simonstl@simonstl.com>
Cc: www-xml-linking-comments@w3.org
Message-ID: <20021114100135.E4400@daniel.veillard.com>

On Wed, Nov 13, 2002 at 04:33:27PM -0500, Simon St.Laurent wrote:
> this proposal
> inflicts ever more verbosity on XPointers, burdening them with ever more
> barriers to human editing and interpretation.
> My favorite example uses the xmlns-local() scheme[1] I proposed
> recently.  If forced to use this poisonous QName mechanism, what once
> looked like:
> #xmlns-local()[restOfXPointer]
> suddenly explodes to:
> xmlns(ns=http://simonstl.com/ns/bogus)xmlns-local()[restOfXPointer]
> which is amusing at best.
> future participation.  I strongly recommend striking this and leaving
> such work to future development, wherever it may appear, unless the W3C
> can demonstrate that it has genuine commitment to future generic XML
> XPointer scheme development which might justify this restriction.
> [1] - http://simonstl.com/ietf/draft-stlaurent-xmlns-local-frag-00.html

  Heh, good luck Simon. that time I agree with you. The xmlns scheme 
purpose was to allow interpretation of prefixes when processing XPointers
schemes expressions inside document. Reusing them for namespacing schemes
mixes layers, and tend to change the way those schemes have to be defined.
I still believe that the schemes definitions must be done in tight coupling
with the associated Mime Type definition for the resource. Trying to reuse
the namespace mechanism to avoid the registry done in practice by the 
set of RFCs at the IETF is not a practical solution because there is no way
to get the semantic or processing description from a random scheme.
  The key point here is interoperability, and to achieve this I don't
see any other mechanism than a well written fragment identifier RFC
defining the schemes bounds to a given Mime Type. Proliferation of
random scheme definitions without a firm mechanism in place to express
their semantic and make sure applications will interoperate in their
interpretation of the fragment identifiers (and hence the schemes used)
should not be encouraged IMHO.


P.S. While libxml implements the xmlns() scheme, it does not implement
     that specific new semantic, so it should not used as a proof of
     implementation for that specific feature of xmlns().

Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Received on Thursday, 14 November 2002 04:23:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:14 UTC