RFC: Attributes and XML-RPC

[Mark Nutter]

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 at 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 at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)