[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: "Reynolds, Gregg" <greynolds@d...>, xml-dev@i...
  • Date: Thu, 23 Sep 1999 09:01:06 -0400

rpc and xml attributes
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 
>the
>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" 
>in
>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:

<person>
   <name>Joe</name>
   <age>39</age>
   <birth_record_at>Lake Wobegon Courthouse</birth_record_at>
   ...
</person>

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 
>all!
>:)

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

<person><name>Joe</name></person>

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@f...>
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@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.