[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: About CodeList for UnitCode
>Whether the information item is an element or an attribute in UBL, >the handling of private values is dictated by the choice of having >adopted the UN/CEFACT ATG2 schema expressions. Ok, I was thinking more broadly than ATG2 (my mistake). >However, the method by which a schema expresses a code list impacts >on being able to extend values. Yep, thats what I was getting at. >UnitCode is one of these, but that it is an attribute is irrelevant >to the issue of it being extensible. Ok. My point was aimed at the suggestion that in order to identify the 'extended' value a NEW attribute would be required since the official attribute would contain 'ZZ'. However given Sylvia Webb's comment this this point is obviously moot. Fraser. On 19/03/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote: > > At 2006-03-19 20:01 +0000, Fraser Goffin wrote: > >What is the situation for using 'private' enum values when the > enumeration > >is carried by a element rather than attribute in UBL ? > > Whether the information item is an element or an attribute in UBL, > the handling of private values is dictated by the choice of having > adopted the UN/CEFACT ATG2 schema expressions. > > > From previous discussions I got the impression that a) the majority of > code > >lists are externalised from schema and > > Indeed they are, as described earlier in the proposal currently being > considered (but not yet formally adopted): > > http://lists.oasis-open.org/archives/ubl/200602/msg00062.html > > >b) that some/many of these are > >'owned' and maintained by other organisations, in which case I would > assume > >that extensibility would be a matter for them ?? (although as noted > earlier > >the current NDR for UBL 2.0 does not mention potential new approaches > >representing code lists and value based validation). > > I personally don't think think that a private value agreed upon by > trading partners would impact on a maintenance organization's > priorities ... if trading partners have to use a particular value > then that is their business. > > However, the method by which a schema expresses a code list impacts > on being able to extend values. For many of the code lists in UBL, > the values can be extended by the proposal under consideration. For > the three coded data types found in UBL 2.0 that have been agreed to > be described by schema expressions consistent with UN/CEFACT ATG2 > schema expressions, extension is not available because of the use of > hardwired enumerations in the document model constraints. > > UnitCode is one of these, but that it is an attribute is irrelevant > to the issue of it being extensible. > > . . . . . . . . . . . . Ken > > > -- > Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-06-12/16 > World-wide on-site corporate, govt. & user group XML/XSL training. > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > This publicly archived list supports open discussion on implementing the > UBL OASIS Standard. To minimize spam in the > archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Alternately, using email: list-[un]subscribe@lists.oasis-open.org > List archives: http://lists.oasis-open.org/archives/ubl-dev/ > Committee homepage: http://www.oasis-open.org/committees/ubl/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > Join OASIS: http://www.oasis-open.org/join/ > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]