- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 28 Jul 1998 19:50:40 -0700
- To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
There is absolutely nothing stopping you from adding in language to DASL which requires that attributes be returned. However I personally believe that attributes are a bad idea for structured data applications. Why would one want to rob oneself of the expressive power of an XML element in circumstances where human readability is not an issue? I can see why you would want to use attributes when a human is marking up a document, name/value pairs are very easy to type in. But in a structured value application, where the ability of humans to enter the data is of secondary to no importance, it seems silly to dumb down your data structures and kill extensability by using attributes. Dumbing Down Data Structures - With an element I can express hierarchy. <a> <b/> <c> <d/> </c> </a> With an attribute I can only express a flat string. a = "bcd" One could, of course, invent a format to imbed hierarchy into an attribute. a = "%b/%%c%%d/%%/c%" But that is clearly silly, one should just use an element. In other words, associativity through containment is a good thing. Killing Extensability - One of the single most powerful features in DAV's property/message object model is its ability to ignore things it doesn't understand. This means I can always extend values without having to fear a loss of backwards compatibility. <a/> can become <a><foo/></a> and my DAV app won't break. If it doesn't understand <foo/> then it will only "see" <a/>. With an attribute I can always define my own hacky way to "add" things. foo="bar" can become foo="bar%blah%ugg%" Where "%" means "If you don't grok what is between the %s then ignore it." But again, this is silly, just use an element. Yaron
Received on Tuesday, 28 July 1998 22:50:18 UTC