MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] A Codelist Issue
From: "Anthony B. Coates" <>
To:
Date: Thu, 11 Mar 2004 22:22:23 -0000
On Thu, 11 Mar 2004 13:37:44 -0800 (PST), <> 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:
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.
