Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Comments on Section 2.6 of XML-Namespaces
 -----Original Message----- From: Andrew n marshall <amarshal@u...> >> As for as your particular example goes, there is "no guarantee from the DTD >> that they mean the same thing" because there is no mechanisms built >> into raw XML DTDs to provide such a guarantee: in fact this is why >> namespaces are needed--to make it clear that an attribute in one >> element type is kin to another. > The element declaration is that guarantee. XML, with the inclusion of the > namespace specification at the element level, describes a way to trace each > element back to an element declaration from which I can compare whether or > not any two elements are related. By this, I am guaranteed that the > attributes of each element of the same element declaration have the same > possible attributes and are complete enough to be useful with it specific > application. Namespace declarations apply to multiple element types. You probably could get the same result using HyTime architectural forms definitions and sticking #FIXED attributes on each individual element type declaration in the markup declaration, it is true. But namespaces need to work in documents without XML markup declarations, and it needs to be terse enough so that it can be set once. (I certainly agree that there are much more interesting things lurking under the surface of the namespace issue, but no-one seems to dispute that.) So element type declarations cannot be a guarantee of anything. > However, as soon as you allow elements to be broken up into their > individual attributes, this gaurantee goes away. Attribute "hijacking" > makes it impossible to maintain the relationship between attributes of a > single element, and impossible to maintain the relationship between the > attributes and the child elements/content. I dont think I agree with your ideas of "hijacking". An attribute is whatever the designer has said it is, for better or worse. E.g., if a document type designer says that all elements types will have an attribute which gives the line number of the element type declaration in the original document, then that attribute has nothing to do with the element type itself, and everything to do with the artifacts of the declaration of that type. Such an attribute has its meaning without any reference to any particular element type being defined. So some attributes are highly coupled to their type, some are highly uncoupled. But perhaps you might agree with me that the way to prevent this problem (i.e., where an attribute in one element is named partially using another element name) is for the original designers of the schema to use explicit namespace qualifiers for all attributes which are not strongly coupled to the element type. These are the particular attributes which perhaps are most likely to be detached. > Actually, if you look at the details of the XLL spec (Part 7, second > paragraph), attribute remapping is limited to the XLL specific attributes. ... That is why I prefaced my comment with "And in any case, in your particular case of hrefs, the XLink draft provides an attribute remapping feature." Rick Jelliffe 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/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe 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
|
|||||||||
