OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Namespace Comments (and dtd encoding)

[ Lists Home | Date Index | Thread Index ]
  • From: "David G. Durand" <dgd@cs.bu.edu>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 6 Aug 1998 14:16:49 -0700

At 10:10 AM -0000 8/6/98, Ron Bourret wrote:
>David Durand writes:
>> ><!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.

I don't see why it's abusive, since it has a clear meaning, that can be
read right out of the instance. I can't think of a reason that you'd want
to do that, but it doesn't seem pernicious. Certainly re-declaring a
namespace prefix inside a context where it's already declared is
potentially confusing, and a good example of why using namespaces can
confuse validation, but it doesn't seem worse than lots of others that
exist whenever namespaces are in use.

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

Now that I think about it, your version seems just fine. Indeed only for a
#IMPLIED attribute does inheritance make a lot of sense. Just chock the
question up to my being dense when I posted. It probably reflects my
DTD-based view of the world, where you just use default or #FIXED values to
explicitly put attributes where you want them. If you care about the
details of how I was being stupid, read the next paragraph.

It's a null-value problem. I was asking a question here, because I didn't
know the answer. Many parsers treat #IMPLIED values as a special kind of
value (the "not-specified" value). I was wondering if we have clear
langauge in the standard about inheritance and #IMPLIED values.


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

Completely right. Charles Frankston also noted one of these typos.

   -- David


_________________________________________
David Durand              dgd@cs.bu.edu  \  david@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@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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS