Re: [ubl] A Codelist Issue

["Anthony B. Coates" <abcoates@londonmarketsystems.com>]

On Thu, 11 Mar 2004 13:37:44 -0800 (PST), <jon.bosak@sun.com> wrote:

> This looks to me like the same use case; the only difference is
> that the trigger for the creation of an expanded special-use code
> list came from IBM rather than BSI.  You're going to go through
> the same committee meetings and the same software revision to
> implement this change that you would in my original example.
>
> So my question remains: how much work total have we saved at the
> expense of using a mechanism we explicitly ruled out for the rest
> of the specification?

There are a couple of issues here.  One is that it is applying the general 
NDR rule on substitution groups to code lists just for the sake of 
consistency would be lazy and short-sighted.  As I pointed out in an 
article on XML.com a while back

http://www.xml.com/pub/a/2003/02/05/wxs-enum.html

there is a big difference between allowing structures to be substituted in 
a Schema, and allowing enumerations to be substituted.  Changing a whole 
structure is likely to break consuming applications.  Although changing an 
enumeration *can* break an application, it is far less likely to do so, 
because it doesn't typically require a change to the application logic.  I 
have no problem with NDR's stance on substitution groups for UBL Schemas 
in general, but code lists are a different beast, and we need to be aware 
that some NDR rules may seek to deal with issues that do not arise for 
code lists.

In spite of this, my personal view is that I don't want to see 
substitution groups in code lists in the long term.  Where Schemas do not 
provide the facilities we need (e.g. enumeration extension), I would 
rather us define the necessary extension mechanism one level higher in the 
code list data model, and then just generate the Schemas we need without 
constraining ourselves.  What Marty has proposed is the only mechanism 
that anyone has come up with for extending code lists in Schemas using 
Schema mechanisms.  I think you raise a very good point Jon that such 
extension is not absolutely necessary in practice, since you can always 
just define a new list that adds the extra codes.  That said, in practice, 
what you are suggesting would often be considered poor practice.  People 
use extension mechanisms not just to implement extensions, but also to 
provide some visible traceability of what has changed between versions.  
Again, not *such* an issue for code lists (text diffs are easy), but 
having an extensibility mechanism provides a comfort factor.

For me personally, I would be happy to see UBL 1.0 go out without the 
Schema-level, substitution-group-based extension mechanism for code 
lists.  Users will soon tell us if they need an explicit code list 
extension mechanism for 1.1, and that will give us time to decide at what 
level of abstraction we should define code list extensions.  Is that an 
acceptable approach?

	Cheers,
		Tony.

-- 
Anthony B. Coates
London Market Systems Limited
33 Throgmorton Street, London, EC2N 2BR
http://www.londonmarketsystems.com/
mailto:abcoates@londonmarketsystems.com
Mobile/Cell: +44 (79) 0543 9026
[MDDL Editor (Market Data Definition Language), http://www.mddl.org/]
[FpML Arch WG Member (Financial Products Markup Language), 
http://www.fpml.org/]
-----------------------------------------------------------------------
This Email may contain confidential information and/or copyright material 
and is intended for the use of the addressee only.
Any unauthorised use may be unlawful. If you receive this Email by mistake 
please advise the sender immediately by using the reply  facility in your 
e-mail software.
Email is not a secure method of communication and London Market Systems 
Limited cannot accept responsibility for the accuracy or completeness of 
this message or any attachment(s). Please examine this email for virus 
infection, for which London Market Systems Limited accepts no 
responsibility. If verification of this email is sought then please 
request a hard copy. Unless otherwise stated any views or opinions 
presented are solely those of the author and do not represent those of 
London Market Systems Limited.