OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] A Codelist Issue


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), <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.
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]