Lists Home |
Date Index |
- From: Mark Nutter <firstname.lastname@example.org>
- To: "Reynolds, Gregg" <email@example.com>, firstname.lastname@example.org
- Date: Thu, 23 Sep 1999 09:01:06 -0400
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
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, <email@example.com>
Internet Applications Developer
Some people are atheists 'til the day they die.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)