Re: xml-namespaces

>>>>> On Sat, 22 Aug 1998 10:57:37 +0700, James Clark <jjc@jclark.com> said:

>  But
> consider our example, slightly modified to make the point even clearer:
> 
>  <elt xmlns:foo="file:///bar" xmlns:goo="file:///bar">
>     <foo:gertie/>
>     <goo:gertie/>
>  </elt>
> 
> Given the intent of namespace declarations, it would be hard to argue
> that subelements "foo:gertie" and "goo:gertie" ought to refer to
> different ELEMENT declarations. 

|James> But they do.  As far as DTD processing is concerned, a colon is
|James> just another name character.  The processing model is that first
|James> you construct an element tree just as with XML 1.0, and second
|James> you associate each element type and attribute name in the
|James> element tree with an expanded name.

I assume that your second part means "you associate each element type
and attribute name in the element tree with *the ELEMENT or ATTLIST
declaration of* an expanded name", right?

I see what you're saying then.  The DTD must then contain the
declarations
    <!ELEMENT foo:gertie ... >
    <!ELEMENT goo:gertie ... >
if you're going to have a resolution according to the normal XML rules.
But that approach has enormous disadvantages, which is why we didn't
consider it:

  1. The DTD now contains two separate declarations for what is supposed
to semantically be the same thing, namely, "gertie" in the "file:://bar"
namespace, with no mechanism within the DTD for connecting them with
each other.

  2. The DTD now contains occurrences of what are supposed to be
placeholders, namely, "foo" and "goo".  If the DTD was developed for a
class of documents, not just a single one, then these placeholders
essentially become set in concrete, hardly the effect you'd want.  In
other words, it ought to be possible within a document to change "foo"
and "goo" to "hot" and "tot" uniformly without changing the document's
interpretation by a processor; that's the whole idea of what
placeholders do.  

  3. Suppose that "foo" is the default namespace in a certain scope and
"moo" is the default namespace in some other scope, with "foo" and "moo"
referring to different namespaces according to their namespace
declarations, as in the following:

  <elt xmlns="file:///bar">
     <gertie/>
  </elt>
  <elt xmlns="file:///bibble">
     <gertie>What a mystery!</gertie>
  </elt>


If the normal XML rules are in effect, the two references to "gertie"
will have to resolve to the same declaration, namely,

    <!ELEMENT gertie ... >

even though two different meanings of "gertie", namely, the one in the
"bar" namespace and the one in the "bibble" namespace, are intended.
And as the example suggests, the two "gertie"s, being in different
namespaces, may have entirely different properties.  Requiring them to
have the same properties would seem totally unacceptable.

  4. The ExternalID in an NSDef becomes purely a string; what's located
at the ExternalID has no effect whatsoever on the interpretation of the
document (or at least no effect indicated by the namespace spec).  The
namespace spec says that an XML namespace is a collection of names,
identified by a URI, which are used in XML documents as element names
and attribute names.  But the spec says nothing whatsoever about how the
information at the URI affects the processing or validity of the
document.

If normal XML rules are used (contrary to what we've proposed), then any
declarations found at the URI have no effect because they're in the
wrong place; to affect the document's processing they have to be in the
DTD.  What's more, if the URI contains declarations, the declarations
will have the wrong names, namely, names without prefixes.  You can't
just attach prefixes to those declarations because a document referring
to the URI gets to specify its own prefixes - after all, as the
namespace spec says, the prefixes are just placeholders.

If the information at the URI isn't a set of declarations, then what
might it be?  Just a list of names, one per line (which is what
"collection" would imply without further explanation)?  Of what use
would that be?  And is that what is intended?

We have nothing whatsoever, not even a statement of general intent,
about how the information located by the ExternalID is supposed to be
used by the XML processor.  That is different from all uses of
ExternalID's in XML itself, where each ExternalID points to information
whose significance and effects are spelled out in the spec (granted that
there's a little room for argument about that in the case of notations).

 * * * *

There may indeed be solutions to all of these problems that we haven't
thought of.  The difficulty with the namespace spec, though, is that if
there are such solutions it provides no indication of what they might
be.

I will be leaving for vacation later today, so I may not be able to
respond to further discussion of this topic until the end of the week.

Paul Abrahams
abrahams@acm.org

Received on Saturday, 22 August 1998 12:26:14 UTC