[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fw: Re: Namespace prefixes optional?
I'm hijacking this to the SML group. Nice idea, definitely not XML -> seems like good potential SML material. ----- Original Message ----- From: <rev-bob@g...> To: xml-dev <xml-dev@i...> Sent: Monday, January 10, 2000 18:57 Subject: re: Re: Namespace prefixes optional? > > > 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@i... > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To unsubscribe, mailto:majordomo@i... the following message; > unsubscribe xml-dev > To subscribe to the digests, mailto:majordomo@i... the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@i...) > 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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
|