Thanks, Jim. I'm slightly amused at the suggestion that genericode would
add complexity, given the format they are proposing. To be fair, at this
stage where there aren't standard genericode libraries, it's true that a
full implementation of genericode would be a burden for an implementor who
just wanted to use genericode rather than build software to support it.
However, restricting their usage of genericode to a simple profile of
genericode, like that used by UBL or FpML, wouldn't burden implementors so
greatly.
My reading of the document is that they have mixed two things together (at
least as I would view it); those two things are (a) the underlying code
lists and (b) the contextual usage rules for when it is appropriate to use
particular codes from particular lists. Genericode is only designed to
deal with (a), while (b) is more closely related to the context modelling
methodology that I'm working on in a separate group in UN/CEFACT.
One of the key questions that they will need to address is whether the
context rules that they have now are fully representative of all of the
context requirements that they will ever have. Another is whether the
rules actually apply to just the codes themselves, or whether they
(implicitly or otherwise) apply to the use of particular codes in
particular elements or attributes in particular XML formats. I think it
is the latter, which means that the format that is being proposed is
tightly coupled to the message structure, with everything good and bad
that goes with that.
I have no doubt that they can create their own tactical XML format that
addresses, in a focussed and compact fashion, the requirements that they
have today. However, a significant question is whether this format will
be able to evolve over time to support all of the contextual rules that
could be required. Also, a narrow vertical format like this is unlikely
to ever have broad vendor support, and that should be taken into account
in evaluating how much of a burden is put on implementers.
My personal recommendation to them would be to uncouple code lists and
context rules so that they can be dealt with separately, and consider
whether a combination of
(a) genericode (i.e. a restricted profile thereof) and
(b) Schematron or pre-calculated subset enumeration Schemas
would provide a suitably flexible solution, potentially with more
broad-based vendor support.
Cheers, Tony.
On Mon, 08 Oct 2007 13:47:08 +0100, Harris, Jim