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: Tim McGrath <>
To:
Date: Fri, 12 Mar 2004 06:38:30 +0800
i sympathize with tony's view. what we are dealing with in enumerations
are not the same as extended the data structures. it also appears to
be a case of if parties wish to do this, they will anyway, . so i am not
sure what mandating against it achieves.
i also what to recognise that this is only one issue for code list
representation. they are other (i suggest more significant) decisions
to be made.
Anthony B. Coates wrote:
> 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.
>
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
