Re: Namespace prefixes optional?
rev-bob@g... 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@a... ___________________________________________________________________ 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@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