|
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
This thread already has a best answer. Would you like to mark this message as the new best answer?
|