[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RFC: Attributes and XML-RPC
At 02:51 PM 09/21/99 -0500, Reynolds, Gregg wrote: >This is true; but it doesn't apply. Attribution is not the same as >structure; the problem is not that we have two ways of doing essentially >the >same thing, its that we try to model two essentially different things in >the same way. Getting rid of attributes fixes the wrong problem. XML and >similar languages represent attempts to model the way we think, and its >pretty indisputable that the mind (well, the Western mind, in any case) >thinks about the world in terms of things, their properties, and their >relations to other things. The warm fuzzy glow Tim has observer comes, I >suspect, when people find they can think with an artificial language in >the >same way they think ordinarily. Or maybe it's the relief they feel when >they realize that the computer geeks have not rammed yet another round peg >through a square hole. > >A man has red hair and a dog. To suggest that his relationship with his >hair (or its redness) is no different than his relationship with his dog >is, >well, shocking. It's an outrage! What's so outrageous about it? A man can lose his dog, and he can also lose his hair, (or his hair can lose its redness :-) Seriously, the problem I see is that there are many places where it isn't possible to determine "correctly" (in some precise definition of "correctness") whether a given piece of data should be an attribute of a particular element, or a sub-element contained within the element. For example, I want to model a directory tree where each directory has access restrictions (as well as files and subdirectories and so on). Is the "access level" of the directory an attribute of the <DIRECTORY> element, or is it an <ACCESS> element contained by the <DIRECTORY> element? If I make it an attribute, then I can supply a default value, restrict possible values to an enumerated list, and make it required -- but each directory can only have *one* access level (unless we want to get into parsing things like ACCESS="public+staff+team1+..." -- ick!). If I make it a subelement, then I can have multiple access levels, but I lose my default and enumerated values. Ok, that particular problem does have a solution: for example, <DIRECTORY> <ACCESS GROUP="public" PERM="R"/> <ACCESS GROUP="staff" PERM="RX"/> <ACCESS GROUP="team1" PERM="RWX"/> ... </DIRECTORY> But on the other hand, we could also do: <DIRECTORY> <ACCESS PERM="R"> <GROUP NAME="public"/> <GROUP NAME="staff"/> <GROUP NAME="team1"/> </ACCESS> <ACCESS PERM="X"> <GROUP NAME="staff"/> <GROUP NAME="team1"/> </ACCESS> <ACCESS PERM="W"> <GROUP NAME="team1"/> </ACCESS> </DIRECTORY> Is it the nature of "GROUP-ness" to be an attribute of "ACCESS-ness"? Is one version "correct" and the other "incorrect"? I don't think so. It seems to me that the current situation is more of an accident than anything else. Attributes are currently justified because of the fact that DTD's happen to allow default and enumerated values only for attributes, so if you need default/enumerated values, you have to use attributes. Secondly, it happens that a lot of XML/DTD work is being done by hand, and attributes are less work to type: <directory access="read"/> -- versus <directory><access><read/></access></directory> The "warm fuzzy" feeling you get from attributes may just be relief that you don't have to type so much! But that's an accidental consequence of the fact that we have to write our XML by hand--a more automated process would have no such feelings. Attributes are a shortcut that make XML easier to code by hand, at the cost of introducing a certain amount of unavoidable ambiguity regarding how a given piece of data should be modelled. IMHO, that is. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Mark Nutter, <mnutter@f...> Internet Applications Developer FORE Systems Guns don't kill people. Bullets kill people. 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
|