[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]