Title: 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
