RE: [emergency] Re: Attributes vs Elements

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Attributes can't have structure, have a limited set 
of non-extensible types, and aren't addressable 
via id/idrefs.  Their order isn't guaranteed. 
You can't put two of the same name in the 
same attlist (must be unique in the scope 
of the attlist).  Namespace handling for 
attributes is squirrely.

Otherwise, use them for metadata as you say.
Even that isn't hard and fast because mapping 
a relational table to a single element with 
atts for holding the content works great as 
long as you treat the content as strings.
  
Avoid long content strings in atts because even if 
the parser works as it should, a generalized 
GUI tends to treat them like fields and 
may not have the allocated space.

One other thing:  don't try to equivocate 
object-oriented fields and XML attributes. 
Not the same thing at all.  XML objects 
are data objects.  Full stop.  Analogous 
to C structs.  This issue became very 
messy in X3D because object-oriented programmers 
want XML to be an object-oriented language 
and it isn't.  VRML is.  We called that 
the impedance mismatch. The VRML tree in which 
objects can have fields and fields can 
have objects couldn't be directly mapped 
without introducing redundant wrapper 
elements.

But the advice that one should never use 
attributes is dead wrong.  It is another 
one of those, "it ain't the things we 
know but the things we know that ain't 
so" bits that seem to be coming largely 
from the Feds.  Attributes prudently applied 
work fine and look logical to the human.
For example, try to do href= with elements 
and watch the expansion once you succumb 
to the temptation to tag substructures in 
the URI.

Check your software and find 
out what internal structures the attributes 
are being mapped to.  Making everything an 
element can result in a much fatter application 
if the system automatically makes all elements 
into objects.  Expensive.

If I had a dime for every time I've seen 
this question since '86.  Sheesh.

www.xfront.com has a rather good collection 
of best practices.

len

-----Original Message-----
From: R. Allen Wyke [mailto:emtc@nc.rr.com]
Sent: Thursday, May 08, 2003 1:10 PM
To: Weltman, Jerry
Cc: 'RCarlton@eteam.com'; EM TC
Subject: [emergency] Re: Attributes vs Elements


Oh boy - you have just stepped into one of the biggest debates of all
times. However, you are right - it is appropriate for us to discuss this
and to do so within the larger audience of the EM TC. I will take what
you have, and run with it (fully realizing that I am sure it will
stimulate some responses :)

The objective of this discussion will be to formalize some *basic*
guidelines we should all adhere to for any XML schemas we develop. I
think it is best we do not set hard and fast rules and that we provide
some wiggle room for each SC, but we do need to be consistent in at
least some fashion. I will include the outcome in the guidelines
document I am working on.

For the context of this debate and to start the discussion, let me list
the basis of how I came to a recommendation:

1. There is no single and always correct answer.

2. You will be hard pressed to find a definitive human definition of
"element" or "attribute", in the context of XML, to provide a single
answer to this question. However, it is generally accepted that
attributes are metadata about its containing element with some implied
inheritance in any subsequent child elements.

3. The 6th design goal of the original XML Recommendation
http://www.w3.org/TR/REC-xml#sec-origin-goals) states that "XML
documents should be human-legible and reasonably clear."

4. There is a technical argument within XML Schema Part 2: Datatypes
(around internationalization), to keep human-readable text out of
attribute values. Under the xsd:string datatype
(http://www.w3.org/TR/xmlschema-2#string), it says:

NOTE:  Many human languages have writing systems that require child
elements for control of aspects such as bidirectional formating or ruby
annotation (see [Ruby] and Section 8.2.4 Overriding the bidirectional
algorithm: the BDO element of [HTML 4.01]). Thus, string, as a simple
type that can contain only characters but not child elements, is often
not suitable for representing text. In such situations, a complex type
that allows mixed content should be considered. For more information,
see Section 5.5 Any Element, Any Attribute of [XML Schema Language: Part
2 Primer].

In not so many words, it says "don't use attributes for human-readable
text". You are not able to include elements, for further description, in
attribute values and things like hard returns are problematic from a
programming standpoint (not too mention a long attribute value violates
#3 above).

5. From a programming standpoint, accessing elements vs. attributes
isn't very different if you use a good parser/processor.

Based on these, I recommend we do the following as part of our
guidelines.

--------------------------
Any and all schema developed by the EM TC and its SCs SHOULD:

1. in general practice separate metadata into attributes.

2. make every effort to keep documents human-legible and reasonably
clear as specified in the Origin and Goals
(http://www.w3.org/TR/REC-xml#sec-origin-goals) of the "Extensible
Markup Language (XML) 1.0 (Second Edition)".
--------------------------

Ok, the gasoline has been poured. I am sure someone will now strike the
match :)

Allen

On Wed, 2003-05-07 at 18:32, Weltman, Jerry wrote:
> Allen and Rick,
> 
> During the Notifications and Messaging SC a couple of weeks ago, I
> brought up the issue that we could be using attributes for some of the
> data instead of elements. The response was overwhelming that we should
> not be using attributes, which is fine by me. But I am wondering
> whether there should be some debate among the TC in general on this
> issue since it seems like we would prefer that all of the TC's XML
> structures have a similar style.
> 
> Or perhaps I am missing something. Is there something about the work
> we are doing that makes attribute-free XML structures an obvious
> common goal?

> Jerry
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency