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: [ubl-ndrsc] Elements vs. attributes: discussion kickoff

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


Here are a few unorganized thoughts to get the discussion going; everyone, 
please respond with your thoughts, and I'll try to formulate votable 
questions as we go:

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

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.

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?).

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

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

Powered by eList eXpress LLC