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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   re: Re: Namespace prefixes optional?

[ Lists Home | Date Index | Thread Index ]
  • From: rev-bob@gotc.com
  • To: xml-dev <xml-dev@ic.ac.uk>
  • Date: 10 Jan 00 11:57:04 -0500

> > That is, by defining "fragment" as belonging to namespace rbns, I am defining the
> > attributes of "fragment" and the children of "fragment" as belonging to the same
> > namespace by default.  With the "p" element, I declare that it belongs to the htmlns
> > namespace, along with (by default) its children and attributes.  With the "b"
> > element, for some reason, I need to attach an attribute from the bubbans namespace
> > - so I mark just that attribute as belonging to a different space.  When "p" closes, so
> > does the htmlns fragment, and the default namespace reverts back to rbns.
> >
> > Simple enough?
> 
> Perhaps too simple. :-)

Then perhaps I've hit the mark squarely.
 
> In the event that you wanted to fragment your data further and the original namespace
> was significant in the new context, you would meed to obtain from the higher level
> element and make it explicit when you do the fragmentation.

Why?  It's a really simple concept - whenever a child (element or attribute) requires a 
namespace which is not the same as its parent's namespace, the child's namespace must 
be explicitly noted.  That's the extent of the relationship - grandparents and such are 
important only so far as defining the parent.  In other words, consider another XHTML 
example:

<htmlns:table align="center">
  <tr><td><table>
    <tr><td><rbns:name>
    <first>Robert</first><htmlns:b>L.</b><last>Hood</last>
    </name></td></tr>
  </table></td></tr>
</table>

That name element is buried deep in layers of htmlns-code, but the only concern is that 
the name tag does not reside in the same namespace as the td element which contains it.  
Similarly, the bold-faced middle initial doesn't look at the preceding code to say "I'm in 
the same namespace as the outermost table element," but instead just says "I'm in the 
html namespace."  Each element can be understood with minimal code - just know the 
parent's namespace, and know how to pass it along as the default for the children.  
Containers and recursion work very well together, don't you think?  Once the b element 
completes (pops), its temporary island of XHTML goes away, and the previous default 
(rbns) resumes control.  Once that name element pops, the previous default (which 
happens to be XHTML again) reasserts itself.

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

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

> and that this was preferable to requiring the manipulation when the data is being
> fragmented.

No, the feeling was that defining a default namespace via inheritance is preferable to the 
endless debate about how:

<htmlns:a href="http://www.gotc.com">

compares to:

<htmlns:a htmlns:href="http://www.gotc.com">

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.

The only thing I'm not really sure about with this model is whether the namespace 
should be explicitly stated on the closing tags - ie., whether my nested-table example 
should really read like so:

<htmlns:table align="center">
  <tr><td><table>
    <tr><td><rbns:name>
    <first>Robert</first><htmlns:b>L.</htmlns:b><last>Hood</last>
    </rbns:name></td></tr>
  </table></td></tr>
</htmlns:table>

I can see arguments both ways - on the one hand, a non-namespace parser will treat 
htmlns:table and table as different elements, and thus should report an improper nesting 
error (right?), so adding the namespace to the closing tag avoids that and also makes the 
inheritance domain a bit clearer to someone trying to read the code.  I could live with 
that, I guess....

> >  Rev. Robert L. Hood  | http://rev-bob.gotc.com/
> 
> I'm guessing you've been quiet because Christmas is your busy period...:-)

No, just haven't had a lot to say.  That, and I'm in the middle of moving *and* 
preparing to attend a science fiction convention this weekend....  (I get to interview 
Bruce Sterling!  Woo-hoo!)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


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