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


I don't have strong feelings about this, but do have leanings.  It's a
bad idea to use a mix of elements and attributes for application data
unless one has a deterministic rule for saying when one should use
each.  If our work is based on CC RTs, then we have a basis - the
primary content is the element and the supplementary components are
attributes.  In terms of readability, style, and understandability, I
think attributes work a bit better.  Using Gunther's examples:

<Amount_0p1 amountCurrencyIdentificationCode="EUR">33.34</Amount_0p1>

is cleaner than:

<Amount_0p2>
  <AmountContent>33.34</AmountContent>

<AmountCurrencyIdentificationCode>EUR</AmountCurrencyIdentificationCode>

 </Amount_0p2>

Be honest, does anyone really *like* an element that has as part of its
name "content"?   I think its kind of goofy.

We also run into the problem of how to handle the cases where there are
only the content components and no supplementary components.  Are we
forced to create a spurious level of nesting, as in the following?

<PickListNotes>
  <PickListNotesContent>Do not ship by FEDEX</PickListNotesContent>
</PickListNotes>

The only way to avoid this is to create an exception that says when the
BIE usage only has a content component, use the BIE element alone rather
than create a child content component.

FYI - X12 decided this week to go with elements only for data, and
attributes only for metadata.  We did this for many of the reasons cited
in this thread, but I also supported the decision because when it was
made we hadn't fully fleshed out the concepts around our lowest level
component.  They now look a lot like BIEs and CCs, and I am leaning
toward changing my mind.  I don't expect that anyone else is going to
change theirs, though.

Mike
--
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