[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] Elements vs. attributes: discussion kickoff
"CRAWFORD, Mark" wrote <snipped>: > >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. FYI - The X12 work has a consensus that matches Mark's position, though we do have one strong dissenter. > >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". Me too. -- Michael C. Rawlins, Rawlins EC Consulting www.rawlinsecconsulting.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC