peace and quiet

I've decided that I have harangued you all enough.

I need to stop otherwise I'll lose the day job, or MathML2 will never
appear or both.

There was a request a while back for an unbiased summary, I fear some
will think this is a biased summary but I tried below to give pros and
cons for the three main options on the table (literal, forbid and
absolute). This is not to discount some of the compromise or variant
solutions as proposed by several people on this list, but the pros and
cons of compromise solutions can perhaps be worked out by subsetting
appropriate properties from the pros and cons below.

After sending this mail I'm going to unsubscribe. I hope anyone doesn't
feel offended that they can't reply. You can always mail me directly
(and my home mail is in the text below as an example as well)
But I don't think I say anything below that I haven't already said
and I need to get out of this list somehow.

Best Wishes

David



LITERAL
=======

Pro:
This is (by any but the most strained reading) what the current namespace rec
defines.

It is consistent (despite some misgivings in some quarters)
with the RFC defining URIs as the requirement to normalise ./ and ../
segments of URI references only applies when converting a relative URI
to absolute form, something that is explicitly not done here.

It gives by far the most natural behaviour when used with XSLT or any
other namespace aware tool. The names of elements don't change if the
document is moved (or worse, passed into a formatter via a unix pipe)
and so styling and queries work in a documentable, consistent manner.

The interpretation here could be phrased as saying namespace names are
URI references. It has been suggested that this should be called
"strings in URI reference syntax" but since URI references are defined
to be strings, this comes to the same thing.  The intention of
using URI syntax is that this allows the choice of a globally unique
identifier (by choosing an absolute URI that corresponds to a
resource over which you have some control). If you choose a URI
reference without these properties (eg "xmlns="foo") then the
identifier, despite being syntactically correct, does not have the
property of being globally unique (this may or may not matter,
depending on context). 

I think this suggestion that you use a URI for a resource that you
have some access to would be an improvement, the current spec
really does nothing to discourage me from using
xmlns="mailto:timbl@w3.org" which somehow does seem wrong.
Note I say control, I would allow mailto:davidc@nag.co.uk, or even
david@dcarlisle.demon.co.uk. A variant would be to suggest that some
file is placed (or could be placed) at the URI which would then
deprecate telnet: and mailto: and similar schemes but I'm not sure
that this is really an improvement.

Con:
It has been argued that this literal interpretation is inconsistent
or "against web architecture" I can't really comment on either of
these claims as the first appears to be wrong and I don't know what
the second means (but I suspect I would disagree with it anyway).

If the namespace is used by a higher level application to retrieve
a resource then the resource retrieved depends on the local base URI.
Some have said this is bad, but it is not so inconsistent with the
behaviour for a link using a relative URI, and if the author of the
document had wanted or needed to ensure a globally unique resource
then he or she could have used an absolute URI.

James Clark disapproves, and (presumably not unrelated) this is
incompatible with the xpath spec, if not xpath implementations.  I do
worry about James' disapproval, It's not that I discount the concerns
of Tim Berners-Lee and Dan Connolly, but to be honest their views of
namespaces (and URIs) seems so disconnected from my experience and
views of the web and XML that I fear we will just have to agree to
disagree on these issues.  But normally I'd be happy to take James'
judgement on these sorts of issues.


FORBID
=======

This is literal with the added feature that relative URI are banned.

Pro:
Without relative URI the absolute and literal options are the same
so most of the discussion becomes moot.

Some (who were there at the time) claim that this is really what the
authors of the spec meant all along and that relative URI references
got allowed by accident.

For the use of a namespace identifier in the literal interpretation
there is never any gain in using a relative URI, typing xmlns:a="a"
may save a bit of typing, but functionally you could use
xmlns="mailto:a" or any other absolute URI with the same effect.
So banning relative URI might be seen as having no loss of
functionality and ensuring good practice.

Con:
It smacks of a typical compromise position that doesn't really please
anyone. 

It is essentially the literal version with an extra run time check on
every implementation on every namespace declaration that there is a ":"
so the URI obeys the syntax of an absolute URI. This check doesn't
really do anything except raise an error in a case that would
otherwise have worked as in the literal example.

It orphans some (perhaps many) existing documents.



ABSOLUTE
========

In this case any relative URI is made absolute according to the RFC
and it is this absolute URI that is compared "character-for-character"
and considered to be the namespace name.

Pro:
It is what xpath specifies

It is hard to find any use case for this behaviour that does not
involve identifying the concepts of namespace and schema. If this is
done it allows the schema for the namespace to be located at the
namespace URI.


Con:
Even for the purposes of locating a schema, the method is unstable, if
you relocate (or copy) the schema document (which is definitely a
definition  of the same schema according to the schema spec) you can
not change the namespace URI in any document to point at the new copy
of the schema as that would change the namespace of the document
(probably making it no longer schema valid) this problem could be
avoided by using schemaLocation to point to the schema, but if you do
that, why hijack the namespace URI to point to schema?

Identifying a namespace and schema is just a bad idea in general.
The relationship  between schema and namespaces is many many (as seen
by looking at any of the currently defined W3C namespaces) and other
things besides schema may be associated to a namespace (rdf, XDR relax
or schematron schemas, dtds, stylesheets, ....) They can not all
realistically share the same URI (although some may claim that content
negotiation should make this possible, this is untested in practice
especially if you have as in XHTML several schemas all with the same
mime type all related to the same namespace), and anyway one of the
stated benefits of using URI reference syntax that it allows _anyone_
to define a namespace, even if they didn't have access to a server or
their own domain (your only hold on the web might be
david1234@yahoo.com free email address, but given that, you can form a
namespace name that is globally unique) If defining a namespace
requires that you run a web server handling complex content
negotiation to serve multiple entity bodies from the same URI then
this significantly raises the hurdles to namespace usage.

elements specified with relative namespace URI are placed into a
namespace based on the base URI of the document (if such exists) this
means that the namespace (and thus effectively all element names to a
namespace aware tool) change if the document is moved or if the URI
used to retrieve the document is typed differently.  This behaviour is
essentially undocumentable and unworkable. Document/stylesheet pairs
that work over a server, when copied to a local disk will fail to work
documents passed through pipes or other contexts with no URI will fail
to parse or be given an inappropriate namespace (depending on exactly
what the behaviour is defined to be in these cases)

If this interpretation, linked to parallel common use of using
relative namespace URI to point to schema documents became common.
then XML mailing lists and newsgroups will be forever swamped with
cries of pain from the poor users who will never figure out why their
stylesheets (or URI references using xpointer URI fragments) broke
because a base URI changed either because a file was copied or some
system used a slightly different URI to access some server.


It invalidates all existing stylesheets that (using a literal
interpretation) use a relative URI when matching documents with a
relative namespace URI. More exactly it invalidates the stylesheet if
its base URI is different from that of the document.

David

Received on Tuesday, 23 May 2000 20:15:15 UTC