Re: Namespace Comments (and dtd encoding)
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format