UBL Naming and Design Rules SC

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

  • 1.  Re: [ubl-ndrsc] Elements vs. attributes: discussion kickoff

    Posted 02-08-2002 19:34
    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