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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


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


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

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
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
 
>I'd like to see the advantages and disadvantages of
>elements described fully in similar fashion.

Again, agree.

>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".

       
Mark



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


Powered by eList eXpress LLC