Re: UBL 5/28/2002: [ubl-comment] NDR Code Lists

["Eve L. Maler" <eve.maler@sun.com>]

Monica Martin wrote:
> *     It might be helpful to weight which of the requirements
> are highest priority.  For example, I believe that
> interoperability and external maintenance would rank close to 
> the top.  That creates the
> question what can you sacrifice for what.  It may not alter
> the outcome selected, however.

We discussed this, and had trouble making really strong differences in 
weight among those top four items.  So I just made them all have the 
same point values...  Luckily, we seemed to find a solution that's 
strong on all of them, so we didn't have to make too many hard choices.

> *     Is maintenance adequately handled in upgradability, context
> rules friendliness and perhaps external maintenance?  I was thinking
> perhaps at some point, the "acquired" code lists may be housed in or
> available via a registry. In that fashion, what performance, storage,
> other reliability, usability, etc. requirements are we affecting by the
> decision (If I am off base, please discard).

Not off base at all...  If we're successful in encouraging the external 
creation of code list schema modules, it would be ideal for them to be 
registered and served out of repositories, same as any schema snippet or 
other asset.  However, they would be subject to pretty much the same 
forces/requirements as all those other assets, which include UBL library 
modules and in many cases trade-community-specific (external) 
customizations.

> *     Some of our assumptions may be affected by the "discussion"
> about code vs. identifier within CCTS.  Any leaveway to account for
> this?

Hmm, excellent question.  My understanding of the discussion is that 
it's focusing on whether there is a relationship between codes and 
identifiers that should be formalized.  If we end up with *some* 
construct that has code-related primary and supplementary components 
(and I think some such thing is needed regardless), then our 
recommendations will still hold.  They will largely hold even if the 
components of such a construct are tweaked somewhat.  We'll have to keep 
an eye on this.

> *     For Multiple UBL Types Method, what controls can be
> place on external organizations?  Could this impede adoption?

We didn't choose this method, but the one we did choose raises the same 
question.  We don't feel that we can force external organizations to do 
anything, but we're going to try to encourage them.  We haven't quite 
figured out the best way to do this encouragement, but the likeliest 
scenario is to define a template/design pattern for external 
organizations to follow, along with using prose and informal 
documentation examples to explain what we'd like them to do.

There's also the option of our extending external datatypes if the 
organization chose not to include the information that we need for 
semantic clarity.  If they chose to include the information in a wholly 
different fashion (e.g., a single "fielded" attribute value instead of 
individual attributes for the supplementary components), it might impede 
*our* adoption of *their* module.

Hopefully our actual detailed recommendations that appear in the NDR 
document will make some of this clearer.  (I have to write this up 
today! yikes!)

	Eve
-- 
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com