Namespace Comments (and dtd encoding)

[Ron Bourret]

David Durand writes:

> 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.

I take it this means I do need to recalculate how prefixes are mapped each time 
there is a namespace attribute?  Any chance this could be clarified in the spec?

> 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.

One thing I find lacking in both versions of the namespace spec is how 
namespaces interact with DTDs.  Granted, hard-wired applications (which are 
probably the majority of all applications) will not ever look at DTDs.  However, 
there are applications that will, such as authoring tools and DTD exploration 
tools, which might build database schemas or Java classes based on the DTD 
structure.

I would like some sort of namespace declaration that applies to the DTD and the 
data.  I assume the point of allowing prefixes (most notably the default prefix) 
to be reused is to make it easier to join files that happen to use the same 
prefix.  If this is the case, why isn't this privilege extended to DTDs?  Or is 
the long-term plan that an instance schema syntax will cause this requirement to 
go away?

> ><!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>
> >
> 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 believe it is legal, which was my whole point.  Granted, it's a matter of 
aesthetics, but I don't like the idea that such abusive constructions are 
possible.

As far as I know, the xmlns attribute is inherited -- this is certainly implied 
by the first example in section 5 of the namespace spec.  (Murata Makoto also 
implies in a separate message that the prefix is not inherited.  Why?)  I also 
assume that is what you are showing in the following example, although I don't 
understand how it is really different from mine.  The value of foo is still 
inherited by the second foo:A -- this should be unaffected by the presence of a 
default.

(As an aside, the first element in the resulting tree is A, not B -- a typo.  
Also, B is not prefixed, so it is in the global namespace, not the second URI's 
namespace.  The lack of a prefix places it in the default namespace.  Since that 
has not been declared, the global namespace is used.)

> 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

I'm beginning to wonder if the namespace problem the highest ratio of apparent 
innocuousness to actual complexity in the universe...

-- Ron Bourret

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)