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
-----Original Message-----
From: Matthew
Gertner [mailto:]
Sent: Monday, 4
February 2002 1:38 AM
To: 'Gregory, Arofan'; Maler, Eve;
Subject: RE: [ubl-ndrsc] Code lists:
discussion kickoff
I think there's one
more (a variation of your 2): use strings, but document the allowed types in
appInfo or some other schema annotation. It's not entirely clear to me how
interoperability is served by having an enumeration and an opt-out (a la xCBL)
or a union of enum and string. People can still specify whatever garbage they
want. I find the huge enumerations of xCBL to be somewhat unwieldly, leading
me to believe that they probably don't belong directly in the schema. Also, in
the future these codelists might be provided by a
more dynamic source (e.g. a web service), so using an enumeration is somewhat
restrictive.
The big drawback of
this approach is that parser validation of the codelist values is not
possible. I'm not sure to what extent this is
useful...
Matt
-----Original
Message-----
From: Gregory,
Arofan [mailto:]
Sent: Thursday, January 31, 2002 7:52
PM
To: Maler, Eve;
Subject: RE: [ubl-ndrsc] Code lists:
discussion kickoff
Folks:
I missed one:
(4) Codelists as Union Type: we could create a "union
type" that allows any one of a set of choices (an enumeration), or a string.
And - assuming someone writes a parser that supports the post-validation info
set - you are supposed to be able to detect the difference afterwards,
assuming that you have access to the schemas when you parse. This is the
cleaner equivalent of the "codelist other" approach used in
xCBL.
-----Original Message-----
From: Gregory, Arofan [mailto:]
Sent: Thursday, January 31,
2002 10:47 AM
To:
Maler, Eve;
Subject: RE: [ubl-ndrsc] Code lists:
discussion kickoff
Folks:
I've thought a lot about this issue, and I believe the
trade-off is this:
(1) Using elements to represent codes is one
possibility, that gives us the
advantage of being able to validate a code from a
controlled list. Also, if
we wrap these in a parent type, the list can be
extended. (Ugly, but it
works.) For companies that have expensive validation
software to handle
code-lists, this isn't a problem, but it is a problem
for the little guys.
We can get free code-list standardization and
validation from this approach,
which I think is good. The down-side is that designing
and maintaining these
code-lists is a bitch. (Many, many versions of our
schemas that do nothing
but update code-lists). Perhaps we could have special
namespaces for
codelists, and have special rules so that versioning
is not done by
namespace but with an attribute? Just a
thought.
(2) Using the "string" approach will absolutely defeat
any hope of
interoperability without benefit of expensive
translation software. The EDI
experience has shown that people will happily invent
their own
non-interoperable codes. In xCBL we allowed for this
with the "CodedOther"
approach: all code lists have an enumeration of
choices, and then a sister
element that holds a non-standard code. If you choose
the "Other" code, then
you have to fill in the string. This approach is not,
in my opinion, the
best solution, but it may be the best we can do with
XML Schema. Using just
a string makes it not necessary to maintain codelists
at all, but sacrifices
much of the benefit of having a UBL, in my
opinion.
(3) Codelists as enumerated data types. This is my
preferred approach - a
codelist is, in fact, an enumeration of specific
semantics, and this format
makes it clear and easier to manage. What we need is
an ability to extend
these (a major failing of XML
schema).
Let me suggest:
(1) Dedicated namespaces for codelists (one per
codelist, or related group
of codelists)
(2) Alow these namespaces to be static - that is, not
versioned.
(3)
Have a "version" associated with the codelist in a way that does
not
change the
name of the namespace. (Could we use XSD "version" for this?)
This way, we could version our structures and our
codelists separately.
This models the best part of EDI, where it is common
practice to update
codelists versions within an older version of message
structures. And all
this, while not throwing away the ability to validate
codelists with a
parser.
The down-side, of course, is that codelists are in a
special class in terms
of how they are versioned and use namespaces, but I
don't think it will be
that confusing - if they weren't special, we wouldn't
be having this
discussion. And this approach is, after all, very much
a part of the
existing EDI standards culture.
Cheers,
Arofan
