OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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

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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]