RFC: Attributes and XML-RPC

Mark Nutter mnutter at fore.com
Thu Sep 23 18:30:55 BST 1999

At 05:14 PM 09/22/99 -0500, Reynolds, Gregg wrote:
> > 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.
>All very true; but don't mistake the instrument for the artisan.  The
>difficulties we have deciding on exactly how to model the world reflect 
>complexities of the world.  We need instruments that reflect the ways we
>think; the notion of attribtution is a pretty basic way of looking at
>things; therefore it is a Good Thing that we have an artificial language
>that reflects this...
>Actually I think there is a big problem of terminology here - "attribute" 
>SGML speak sometimes refers to a syntactic feature of (meta-)language,
>sometimes to semantic content modeled by that feature.  My remarks are
>driven by semantic notions, whereas I think much of the discussion of
>attributes is driven by a focus on the particular syntax of XML.  Too bad:
>stifles innovation, IMO.  The representation of semantic attributes (along
>with hierarchical structure) could be modeled by many different syntaxes;
>it's not clear (to me at least) that XML is the best of them.

I think we're fairly close to agreement.  For example:

   <birth_record_at>Lake Wobegon Courthouse</birth_record_at>

According to the XML 1.0 rec, the above <person> element contains <name>, 
<age>, and <birth_record_at> child elements.  They are not "attributes", as 
the spec defines attributes, yet functionally they could be considered the 
attributes of the <person> being represented.  The above meets your 
requirement that our model accurately represent the fact that real-world 
things have related attributes, yet no XML "attributes" were used.

Hence, it might be argued that by embedding data within a tag, and calling 
that data "attributes," we're actually confusing things by artificially 
imposing an arbitrary distinction between information (attributes) that 
belong inside a tag and information (attributes) that belong in a child 
element.  The problem is that there is no clear way to specify which 
attributes are XML "attributes", and which are "content."  Syntactically, 
of course, if you need default/enumerated values, then you have to use XML 
elements, and if you need multiple instances of the same type of 
information then you have to use child elements.  But that might be just an 
"accidental" result of using DTD's to define things.  It wouldn't be too 
hard to come up with an alternate definition mechanism that would let you 
supply default and/or enumerated values for character data within elements, 
in which case the syntactic need for XML "attributes" would disappear.

> > The "warm fuzzy" feeling you get from attributes may just be
> > relief that
> > you don't have to type so much!
>Nope.  I use emacs - one big honkin' macro and I don't have to type at 

Woo woo!  :-)

> > 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.
>Nah.  They don't introduce any ambiguity that isn't there already.

The ambiguity I'm referring to is the fact that, when writing a DTD, you 
have to decide if you're going to represent, say, a person, as either

<person name="Joe"/>

or as


There is no information conveyed by the one representation that is not 
conveyed by the other -- both represent a person whose name is 
"Joe".  Which is the "correct" way to represent Joe?  It's ambiguous.  If 
two features do exactly the same thing, then one of them is redundant.

IMHO, of course.  :-)


Mark Nutter, <mnutter at fore.com>
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.

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)

More information about the Xml-dev mailing list