OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] more QName madness

[ Lists Home | Date Index | Thread Index ]

On Sat, Nov 16, 2002 at 12:08:19PM +0000, Henry S. Thompson wrote:
> Daniel Veillard <veillard@redhat.com> writes:
> >   Well currently interop is not addressed, there is no way to get the 
> > semantic of the XPointer from the namespaced scheme name.
> Surely that's not the point -- the point for interop is simply that
> any given application knows the names of the schemes it implements.
> Reasonable guarantees of uniqueness of scheme names, such as that
> provided by using URIs via QNames, are all that's required to prevent
> mistakes here.

  Sounds like the refrigerator Infoset compliance joke. You garantee
to not make an error on input so that sufficient for interop compliance.
If you want real interop, either you limit the shemes using a registry
or if you open up the registration, then you at least provide explanation
on how to get to the semantic of the sheme operations.

> No-one _ever_ claimed that using QNames would mean that a
> general-purpose XPointer processor would be able to look up the scheme
> name and find some operationalisable description of scheme semantics.

  Yes, and since this is not possible and that one need operationalisable
description of scheme semantics to process the scheme (contrary to XML 
namespace used to provide unicity of element and attribute names, the 
semantic is required for functional processing of schemes).
  Also the existing RFCs describing URI say that the meaning of the fragment
identifier is to be found in the description of the Mime-Type associated
to the returned resource. The scheme you suggest invites to the proliferation
of schemes without having a mechanism in place to insure that binding 
to the description of the Mime-Type. Mime-Type are limited, but at least
their description is a place to make the association to the semantic of
the associated scheme.

  This is a very concrete probleme, IMHO far more annoying than the risk
of collision of scheme names, there is no way to find the semantic of a
scheme. Suppose I start filling all the returned pages from the rpmfind.net
servers with a scheme anchored in http://veillard.com/rpm/scheme , how
are you gonna build an application understanding them ? Without the semantic
there is no use possible of a scheme. So one will have to find that semantic.
How ? If it's clearly stated that schemes are defined as part of the
Mime-Type definitions, then we go back to a registry anyway, if not tell
me how to use them !

  Schemes are my baby in a way, I do think they are a very important
feature, but I can't see how suggesting to open up their usage without
a way to also bind the definition can be useful and not actually prevent
them from being deployed. If they don't work in practice, people won't
use them, and support is not gonna grow. Be realistic, there is no way
people providing browsing support are gonna start chasing schemes defined
randomly, you will need a registry, if you don't bind to the existing
IETF suggested practice to define them I'm afraid it will at best turn
in a big mess, and at worse never deploy...


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS