UBL Naming and Design Rules SC

RE: [ubl-ndrsc] Code lists: discussion kickoff

  • 1.  RE: [ubl-ndrsc] Code lists: discussion kickoff

    Posted 02-04-2002 07:23
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl-ndrsc message

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


    Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff


    Title: Message
    Folks,
     
    I also agree with the view on eliminating large code lists of enumerated values fro the UBL specification. We should really be specifying the source of the codelists aka some ISO standard, and allowing this to be the basis of the values used in the element. Having a standard list of codes within UBL is in my view helping UBL not becoming a useful standard.
     
    An earlier comment by Phil Griffin pointed out:
     
    "Seems to me, as an example, if I only ship to the US and Canada, that for my document only USA and CAN might be valid out of the list of all country codes. What benefit would I get from JAP and FRA being valid?"
     
    So why not let us specify only CAN and USA (and maybe AUS) in our application, provided it meets the context in which it would be used. It should not be difficult for an application to also validate these choices at run time. For example we could have a middleware application receiving and processing a SOAP message that checks to see if CAN, USA or AUS is used in a <Country/> element. If the application MustUnderstand the three choices, then let the application do so. If it doesn't work, it sends the message back to the originating application. Also we need extensibility for legacy data as well. The recent introduction of the Euro is a good example. When the old currencies are no longer part of the ISO standard - what do we do with the legacy data we need to exchange?
     
    Also if we stick to strict enumerated list we would be placing to rigid a control on what UBL documents could contain. I had a look through the party.xsd sample that was sent by Arofan. While on the surface everything appeared to be in order, I could not begin to comprehend the need, for example,  for the list of AgencyCode's that were available. I'm sure this list satisfies the historical use for the EDIFACT 3055 (Code list responsible agency code) and X12 559 (Agency Qualifier Code) uses from which it was derived, but what utility would it be to a SME in outback Australia or deepest darkest Africa. Most notably these SME's would need to have some way of specifying their own Agency's. Sure it is fine for maintaining the link to the EDI ways, but aren't we supposed to be developing a language that will have "utility" for all of us and not the top 1000 companies that could afford to implement EDI.
     
    I hope this adds a bit of fuel to the debate without causing any offence.
     
    Regards,
     
    John Dumay