Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RFC: Attributes and XML-RPC
 Erik James Freed wrote: > My thinking is that it is considered harmful to have two ways of doing > such semantically equivalent things, because this can easily lead to more > complicated implementations > and more complicated interfaces than is optimal. This rule of course can be > immediately broken if there is some truly useful distinction between the two > (they are not truely equivalent). The case > Tim is making for breaking this rule is one of readability e.g. that > attributes are more readable for certain features. Presumably this > readability advantage would diminish and reverse where attributes are long > enough to really want to be on multiple lines. So you have a feature where > the lenght of the string representing the value determines an implementation > change (kind of fugly as data modeling goes). I can see either side, but I > think that > readability is a troublingly subjective metric. Another argument is that > this seemingly small semantic aliasing may cause more problems in the future > as new features are added. Note the effect on query languages for instance. > God knows they need all the help they can get to limit complexity. > > I would conclude that attributes were a truly unfortunate decision, and we > will live to regret it more in the future, but does the impact of this > decision have enough of an force to reverse a long standing language > feature? I kind of doubt it, I bet that there is now enough cultural > momentum to prevent that. Personally I think it is bad practice to contain data that an application uses directly like a price, or a coordinate even though it is probably more intuitive to read: <Rectangle x="0" y="0" width = "0" height="0"/> than <Rectangle> <x>0</x> <y>0</y> <width>0</width> <height>0</height> </Rectangle> A rectangle will never really change and you cannot really extend a rectangle. But attributes are very useful for describing the context with which the element should be treated, for example namespaces. Namespaces nodes as they are called in XSLT are not really relevant to the application itself but delimit the scope of a "namespace" and define what the namespace prefix actually means. Really, I would of prefered to delimit namespace scopes using PI's as in the long run I think would of been much more extensible and not so obtrusive, but that is a debate that has been rehashed over and over again and with no success. But it would be nice if namespaces were defined by PI's so that only the XML parser needs to deal with the PI's when constructing a QName and let the application do whatever it wanted with attributes to describe the context of an element AS IT APPLIES TO THE APPLICATION PROCESSING IT, if anything. If you are going to actually use "Namespaces in XML" you are probably better off not using attributes at all so that if someone actually looked at your element tree, they could choose to ignore attribute processing altogether instead of having to check each attribute to see if it is a namespace node before presenting it to the application. I myself would rather use a namespaces solution that works (even if non-standard and home brewed) than something which is totally broken in concept as well as implementation. Tyler 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 (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
|
|||||||||
