For literals: why I changed my mind

David Carlisle wrote:

> Of course even the `case A' situation is not considered flawed
> by those people arguing for the literal interpretation, which has
> always been the majority view of any list that has ever discussed
> this, as far as I can tell.

I wonder if it would be helpful if I explained why I originally opposed the
literal interpretation but now support it.

When I first studied the namespace spec, I was very troubled by the question of
how one constructs the DTD for an XML document that employs multiple
namespaces.  I also was under the mistaken impression that the namespace name
was at least partly intended to locate either a DTD or a schema that would
define the names used in the namespace.  (That pseudo-duck again!)  It seemed
clear to me then, and still does, that one should have a single publicly
accessible DTD for the namespace that would not have to be rewritten according
to the particular prefixes used to invoke the namespace within an XML document.

But David (I think it was him) pointed me at the MathML2 DTD, which uses
parameterization to deal with that difficulty.  By controlling the environment
in which the DTD is referenced one can propagate the prefix throughout the
DTD.   (Personally I think that's worth noting somewhere as a non-normative
comment in the namespace spec.  If the XML spec can discourse on autodetection
of character encodings, surely that would not be out of place.)

I read the "a namespace name is just a name" mantra in lots of places, of
course -- but it seemed then to me to be just plain wrong.  Obviously -- or so
it seemed -- the namespace name is a URI reference so that one can retrieve
metadata of some flavor with it.

However, I now see that any attempt to treat the namespace name as anything
other than an uninterpreted character string can't help but run into thorny
questions of what identity really means.   The literal interpretation bypasses
all of those questions.  The URI-ness of the string simply has nothing to do
with its interpretation.   Simon St. Laurent put it more strongly in a recent
message: it was a mistake to use URI's for that purpose in the first place
(hope I'm not misquoting you, Simon).   But as long as we're stuck with that
mistake, I believe we're best off to treat namespace names as what they should
have been in the first place: arbitrary character strings whose interpretation
is not defined by any XML-related specification.

OK, so what about relative URIs, which we're told are out there in documents --
particularly customer-generated documents -- that are beyond our ken and
control?  Programming language standardizers have a way of dealing with that
kind of thing: they invoke the magic words "implementation-defined".  Yes,
Microsoft in particular may be using relative URIs, but is there any necessity
for XML specifications to spell out what they mean in the Microsoft context?  I
think not.

Paul Abrahams

Received on Monday, 19 June 2000 17:34:03 UTC