[
Lists Home |
Date Index |
Thread Index
]
- From: Mark Nutter <mnutter@fore.com>
- To: xml-dev@ic.ac.uk
- Date: Wed, 22 Sep 1999 09:00:40 -0400
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@fore.com>
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@ic.ac.uk
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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|