Namespace Comments (and dtd encoding)

[David G. Durand]

At 9:55 AM -0000 8/5/98, Ron Bourret wrote:
>> The point is - I think - that the DTD parser is completely dumb. It doesn't
>> care about colons (except to recognise that they are legal). I assume -
>> though I haven't tried it - that this DTD will validate the example with
>> any of the current parsers.
>
>My first reaction was that it was dumb, too, but at some point, it's got
>to get
>smart.  That is, it needs to resolve the prefixes in the DTD to determine
>what
>elements are being defined.  As far as I can see, the new spec does not
>define
>when this occurs.  The only relevant information I can find is that it
>specifically omits the 'Prefix Declared' constraint from the DTD productions
>([12]-[17]).
>
>In the worst possible case, you would have to resolve the DTD prefixes every
>time there is a change in namespace declarations.  Not only is this extremely
>ugly, it would lead to abuse such as the following, where the second A is
>in a
>different namespace than the first A and both A's are declared with a single
>element declaration:

Well, it's not ugly, it allows re-use of prefixes without creating
conflicts. This is the point of a local scoping mechanism. A prefix is
essentially a variable, bound to a URI. the draft allows these variables to
be rebound within limite hierachically nested scopes (just like all modern
programming languages). These scopes are in one-to-one correspondence with
the element structure of a document, which for documents is the most
relevant hierarchy.

It's true that DTDs cannot be aware of this right now, but it's also true
that local scoping is most useful incases where people want to add markup
to existing document intances (a key scenario for namespaces). It's also
true that after such dynamic markup, DTD validation is going to fail
anyway.

><!DOCTYPE A [
><!ELEMENT foo:A (B)>
><!ELEMENT B (#PCDATA, foo:A)*>
><!ATTLIST A xmlns:foo CDATA #IMPLIED>
><!ATTLIST B xmlns:foo CDATA #IMPLIED>
>]>
><foo:A xmlns:foo="[first URI]">
>   <B xmlns:foo="[second URI]">
>      <foo:A>
>         <B>asdf</B>
>      </foo:A>
>   </B>
></foo:A>
>
>A more reasonable solution might be a namespace constraint that says that all
>DTD prefixes must be declared on the root element.  However, without thinking
>this through too carefully, I suspect you lose a good deal of flexibility.

This very was considered very carefully by the SIG and the WG, and the
decision was taken that you did lose flexibility.

The document you give seems legal to me, although I'm not sure about the
use of #IMPLIED -- what is the status of the value of the xmlns attribute
of the second foo:A, given that there's no value in the instance, and no
default or fixed value?

I've not the time to track this down right now, but the effect of #IMPLIED
in attribute inheritance is worth checking, I think.

On the other hand, the following is unexceptional:

<!DOCTYPE A [
<!ELEMENT foo:A (B)>
<!ELEMENT B (#PCDATA, foo:A)*>
<!ATTLIST A xmlns:foo CDATA "[first URI]">
<!ATTLIST B xmlns:foo CDATA "[first URI]">
]>
<foo:A xmlns:foo="[first URI]">
   <B xmlns:foo="[second URI]">
      <foo:A>
         <B>asdf</B>
      </foo:A>
   </B>
</foo:A>

The result of that is the following tree:
[first URI]:B
   [second URI]:B
      [second URI]:A
         [second URI]:B


   -- David

_________________________________________
David Durand              dgd at cs.bu.edu  \  david at dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



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