xml-dev - Re: XML Namespace

[Steve Dahl <sdahl@goshawk.com>]

Tim Bray wrote:

> At 04:17 PM 8/30/98 -0400, Steve Dahl wrote:
> >For example, if the file a.dtd declared one element ns:x, and the file
> >b.dtd declared another element ns:x, how could I use both of them in the
> >same document, without copying one of the DTDs and changing the prefixes
> >in the copy?
>
> The namespace draft clearly forbids mapping one namespace to two
> different prefixes.  So in the instance, you'd probably have to
> change the ns:x to ns_2:x or something.  Which meant that if you
> wanted to validate it against b.dtd, you'd have to change it
> in b.dtd as well.
>
> BUT (and this is the hard part) you couldn't validate the merged
> document against b.dtd anyhow because it won't know about the elements
> from a.dtd.  So you're going to have to figure out how to make
> a merged dtd.  Which is hard.  But once you've figured that out,
> fix up the namespace collisions while you're doing the merge. -Tim

I don't think that the draft forbids mapping one URI to different prefixes, or
mapping one prefix to different URIs. I'm not sure what the effect is if a nested
element maps an already mapped prefix to a different URI, as in:

    <ns:doc xmlns:ns="http://www.foo.com/ns1">
        <ns:chapter xmlns:ns="http://www.baz.com/ns2">
            ...
        </ns:chapter>
    </ns:doc>

If it worked, the effect is obvious enough, but it's not clear that it should, or
that most parsers would necessarily handle it correctly unless the spec points it
out as something to watch out for. Certainly, a prefix that keeps changing its
binding through the document is going to result in a document that is very hard
for a human to read.

As far as validating the document goes, I could create a copy of one of my DTDs
and within that copy, I could change all occurrences of the old prefix (ns) to
the new one (ns_2), then use ns_2: in my document wherever I want to use elements
or attributes from the second DTD. This is quite feasible if I am the author of
at least one of the DTDs. It's less reasonable if _both_ of the DTDs are
standards from different standards bodies, because now my copy of the standard
DTD will begin to diverge from the standard over time, and is no longer
"standard".

If DTDs had the same sort of scoping rules as documents, and had to map the
prefix to a URI before they could use it, I can imagine several solutions to my
hypothetical conflict:

---

The document might be able to map one of the two URIs to a different prefix.
Since the DTD's elements and attributes would now be defined relative to a URI,
and not defined relative to a prefix, the two DTDs would now fall into different
Namespaces, and the document can assign those Namespaces any prefixes it wishes.
Where this breaks down is that general entities contain literal text, which may
include prefixes, and these prefixes would have to be remapped if the document
were using different prefixes than the DTD. This is feasible, but it suggests
that an entity no longer has replacement _text_, but replacement _structure_. It
may also suggest that entities are no longer global, but are defined in a
Namespace, and that they should be allowed to have qualified names.

---

The document could use the same prefixes as the DTDs, but remap the prefix on
almost an element by element basis, as in the example I mentioned earlier:

   <ns:doc xmlns:ns="http://www.foo.com/ns1">
        <ns:chapter xmlns:ns="http://www.baz.com/ns2">
            ...
        </ns:chapter>
    </ns:doc>

This approach is very ugly, but it also fails to work if you have a tag like:

    <ns:chapter ns:xyz="...">

The above tag is inexpressible if the element belongs to one namespace
("http://www.foo.com/ns1"), and the attribute belongs to the other
("http://www.baz.com/ns2").

---

Both of these require that the DTD declare which URI it wants to associate with
its prefix (if it uses multiple prefixes, it would have to declare all of them).

If Namespaces are not deployed commercially until we have a replacement for DTDs
in which the document is not required to use the same prefix as the data
description, then this may be a non-issue. But if Namespaces are not going to
presuppose what the replacement for DTDs will be, or when it will arrive, it
might be useful to think about how Namespaces could be a little more bullet-proof
about prefix collisions.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)