[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RFC: Attributes and XML-RPC

  • From: Mark Nutter <mnutter@f...>
  • To: xml-dev@i...
  • Date: Wed, 22 Sep 1999 09:00:40 -0400

access attributes of xml
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.