RE: [ubl-ndrsc] Elements vs. attributes: discussion kickoff

["Eve L. Maler" <eve.maler@sun.com>]

At 11:18 AM 1/31/02 -0500, CRAWFORD, Mark wrote:
>Eve wrote -
> > One of the more critical areas we need to decide is "elements vs.
> > attributes".  Gunther's position paper is here (he's going to
> > update it soon):
> >
> > 
> <http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-stuhe>http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-stuhe 
>
>c-elemvsattrib-01.doc
>
> >I think the analysis in this paper about advantages and disadvantages of
> >attributes is mostly on target (I have a few quibbles that I'll try to
> >write up soon).
>
>Agreed.  I sent Gunter a marked up version of his document this morning

BTW, my main quibble was that there was inconsistency in saying that it's 
easier to use attributes than elements with the DOM, and then saying that 
elements are easier to handle in APIs.  My understanding (not first-hand) 
is that attributes are inefficient in DOMS, and to rely on them too heavily 
means a performance hit.  That said, I kind of doubt we'll eliminate them 
100%, even at lower levels...

> >I wonder, though, if the draft proposal in this paper favors attributes too
> >heavily.  With the advent of XSD, there is little you can do in attributes
> >that you can't do in elements -- even default values can be assigned to
> >elements that have a simple type.  And even the code list case (which seems
> >like an obvious candidate for attributes because it often uses a closed set
> >of values) isn't crystal clear, because we know we need to add all kinds of
> >metadata and mechanisms to code lists to make them work.
>
>My position on this is use attributes only for document level information. 
>This means that for the most part only built-in document level attributes 
>such as xml:lang, id and idref should be used and elements should be used 
>for all other transmitted data.  My understanding is there are parsing, 
>ordering, and performance issues surrounded with attributes.  I also 
>believe that by enforcing attributes at the document level, we will 
>provide clarity, avoid confusion, and enable better structuring.
>
> >Finally, I wonder if this paper can be expanded to explore the question of
> >empty elements too.  This topic came up in the F2F last week (are empty
> >elements "leaf nodes"? should they be used only as "attribute hangers" or
> >also as presence/absence boolean indicators? how should we name them?
> >should we allow them at all?).
>
>Most strongly disagree with the concept of using empty elements as 
>"attribute hangers" and "Boolean indicators".

If we don't use them for either purpose, then there's practically no 
rationale for using them at all.  Which is fine, I'm just pointing it out...

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com