Namespace prefixes optional?
rev-bob at gotc.com
rev-bob at gotc.com
Mon Jan 10 16:57:53 GMT 2000
> > 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 at 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 at ic.ac.uk the following message;
unsubscribe 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)
More information about the Xml-dev
mailing list