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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Namespace prefixes optional?

[ Lists Home | Date Index | Thread Index ]
  • From: Marcus Carr <mrc@allette.com.au>
  • To: xml-dev <xml-dev@ic.ac.uk>
  • Date: Tue, 11 Jan 2000 08:59:08 +1100


rev-bob@gotc.com wrote:

> Maybe I *did* make this too simple; you seem too eager to make it far more complex
> than it really is.

Too many sugary drinks, Rev. I replied in the spirit of providing what I believed the motivation
for the decision was. I'm not eager to make anything anything.

> > I suppose the feeling was that you can create your data in the way that you described,
> > then apply a simple tool to make the namespaces explicit,
>
> No, no, no!  No more tools required!  At all!  Say it with me: "A child element inherits
> the namespace of its parent, unless otherwise specified.  An attribute inherits the
> namespace of the element to which it belongs, unless otherwise specified."  Boom.
> Done.  Clear?

Absolutely. So, could you tell me what namespace the following fragment inherits?

<Nappy Condition="dirty"/>

Probably not, because although there may have been a namespace associated with an ancestor
element, the relationship is lost when the element is removed from that context. Boom, err,
Done...

> With the inheritance model I've laid out, these are explicitly identical - because in the
> first example, href *inherits* its namespace from a, which is defined as being in the
> htmlns namespace.  A namespace-compliant parser would hit the htmlns:a element, note
> it as an a element which belongs in the htmlns space, and treat all the children and
> attributes of that element as defaulting to the htmlns space.  The href attribute is next in
> line - no explicit namespace, so it belongs to the default - htmlns.  When the a element
> closes, so does its domain of inheritance; the parent has no more children, so it cannot
> pass on its namespace to anything else.

As stated above, that only works when the child element has the correct ancestor to inherit
from, but that is only one application of namespaces, and a fairly uncomplicated one at that. As
soon as you use the element in another context but want to preserve the namespace, you need to
formalise it.

I really don't see what the difficulty is - you can do what you want to on the data creation
side. If you want namespaces to be inherited, then they are. Now all you have to do is translate
your data to make it unambiguously useful to anyone (including you) who might want to poach a
fragment without having to assign a new namespace to it.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe 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