RE: [ubl-dev] Code list extensibility and substitution groups

["Andrew Chilcott" <andrew.chilcott@stpsolutions.com>]

Having lived in the UK most of my life, I can assure you that I have never seen
GBp used anywhere.

> -----Original Message-----
> From: Adrian Walker [mailto:adrianw@snet.net]
> Sent: Sunday, February 20, 2005 1:11 PM
> To: William J. Kammerer
> Cc: ubl-dev@lists.oasis-open.org
> Subject: Re: [ubl-dev] Code list extensibility and substitution groups
> 
> Hi --
> 
> A tangential thought...  I believe that in common UK usage, GBP and GBp
> mean different things, by a factor of 100 !
> 
> It's good to see that ISO does not sanction the latter.  But if it's tucked
> away somewhere in XML, it could lead to dramatic mistakes.
> 
> One wonders how many people think they are 100 times richer than they
> really are.
> 
>                                  Cheers,  -- Adrian
> 
> 
> 
> INTERNET BUSINESS LOGIC (R)
> www.reengineeringllc.com
> 
> Adrian Walker
> Reengineering LLC
> PO Box 1412
> Bristol
> CT 06011-1412 USA
> 
> Phone: USA 860 583 9677
> Cell:    USA  860 830 2085
> Fax:    USA  860 314 1029
> 
> 
> 
> 
> At 08:15 AM 2/18/2005 -0500, you wrote:
> >I'm not going to outright disagree with my good friend David RRR Webber
> >(I've promoted him to have 3 middle initials, 2 short of the future
> >King). But I'm not sure "ad hoc extensibility of standard code lists
> >[is] really a requirement."
> >
> >Putting aside versioning, if a value is constrained to contain an ISO
> >4217 currency code, then I rightfully assume any of its values can be
> >used to form a valid document, for example. Now, it may be a business
> >requirement that the supplier only accepts prices in USD and EUR, but it
> >would be truly frustrating to have my XML tools or translator bark at me
> >because I used GBP - what to me appears to be a perfectly sound, hard
> >currency. It would be hard to trace back through the rat's nest of
> >schema and overrides to see just why this is happening - why a valid ISO
> >4217 code is causing me conniptions. IF IT'S A PAROCHIAL BUSINESS
> >REQUIREMENT, THEN SCHEMA DO NOT SEEM TO BE THE APPROPRIATE PLACE TO HIDE
> >THE REQUIREMENT. I guess I'd rather see the requirement that only
> >Dollars and Euros are used by my trading partner within an ancillary
> >piece of documentation - or even in a response message saying "I
> >expected only EUR and USD."
> >
> >On the other hand, code value restriction might have found a place in
> >X12 and EDIFACT EDI implementation guidelines because codes were used
> >all over the place to do things names are used for in XML - e.g., to
> >differentiate delivery dates. The only way you could make the DTM
> >segment make sense is if you "restricted" (in the printed guideline) the
> >code value list to the 2 or 3 sensible values out of an EDIFACT codelist
> >containing hundreds. But a Delivery core component gives you only those
> >"Delivery" dates that make sense in that context, e.g.,
> >ActualDeliveryDateTime and RequestedDeliveryDateTime. There's certainly
> >no need for code restriction in UBL to differentiate Delivery dates,
> >because there are no codes - only element names. But that's the primary
> >reason folks restricted code lists in EDI; why does it have to be
> >carried over to core components and XML?
> >
> >William J. Kammerer
> >Novannet
> >Columbus, OH 43221-3859 . USA
> >+1 (614) 487-0320
> >
> >----- Original Message -----
> >From: "David Webber (XML)" <david@drrw.info>
> >To: <jon.bosak@sun.com>; <ubl-dev@lists.oasis-open.org>
> >Sent: Tuesday, 15 February, 2005 12:36 PM
> >Subject: Re: [ubl-dev] Code list extensibility and substitution groups
> >
> >
> >Jon,
> >
> >This of course has been EDI 101 since time began.
> >
> >Good that we are moving to tackle these issues.
> >I've provided my feedback <resp/> below.
> >
> >I believe the new ebXML solution stack including
> >BPSS V2 and ebMS V3 and registry V3 is well
> >equipped to solve the needs here - and my
> >thought would be to lean there first, and let
> >W3C XSD catchup later - if and when it indeed
> >does.
> >
> >Thanks, DW
> >
> > >
> > > There are three key questions to be decided here:
> > >
> > >  - Is it necessary to provide for the kind of extensibility
> > >    described in Requirement 26?  In other words, is ad hoc
> > >    extensibility of standard code lists really a requirement?
> > >    This is basically a business question.
> >
> ><resp> Absolutely - and preferrably context / role driven. </resp>
> >
> > >
> > >  - If it is a requirement, is the substitution group mechanism of
> > >    XSD the right way to meet it?  (The UBL 1.0 Naming and Design
> > >    Rules explicitly forbid the use of substitution groups in other
> > >    UBL schemas, so adoption of subsitution groups to provide for
> > >    code list extension would mean that an exception to this rule
> > >    would have to be made for code list schemas.)  This is
> > >    basically a W3C Schema philosophy question.
> >
> ><resp> Schema is just not equipped for this, and I'm not
> >     sure the W3C want to support B2B needs.  Maybe that
> >     has changed - but historically their position has been
> >     "not our problem". The biggest *gotcha* is versioning.
> >     Even if their mechanism does partly do what you want;
> >     EDI 101 teaches us that versioning is essential as
> >     codelists change - and versioning at the element /
> >     attribute level again is a blindspot for XSD.</resp>
> >
> > >
> > >  - If substitution groups are indeed an acceptable mechanism for
> > >    this purpose, do currently available XML tools actually provide
> > >    sufficient support for it?  This is a question of fact upon
> > >    which we lack sufficient data.
> > >
> > > In a preliminary discussion of this issue at the recent UBL TC
> > > meeting in McLean, the following use cases were identified:
> > >
> > >    1. It is necessary to add a value to a standard code list, or
> > >       remove one, or both.  Sometimes this change should
> > >       eventually be reflected in an updated version of the
> > >       standard code list itself (for example, the addition of a
> > >       new country code), and sometimes it should not (for example,
> > >       the inclusion of a nonstandard currency code to accommodate
> > >       a particular trading scenario, or the removal of certain
> > >       country codes to implement national trade restrictions).
> ><resp> Versioning is crucial as noted above.  ebXML registry can
> >            fullfil this much better - using business-noun definitions
> >and
> >            referencing them via LID(UBL-id) lookups to retrieve the
> >            actual codelist at runtime.  V3 of Registry supports this.
> ></resp>
> > >
> > >    2. A standard code list is revised, but users must support an
> > >       old code value alongside the new one.  For example, the
> > >       value "piece" in UN Recommendation 20, Units of Measure, is
> > >       represented by the code "PCE" in older versions and the code
> > >       "C62" in newer versions.
> ><resp> Switching between code values requires transform technology.
> >             This is why OASIS CAM templates are designed to augment
> >             schema by providing exactly this functionality.
> ></resp>
> > >
> > >    3. Different trading partner agreements may require different
> > >       restrictions or extensions of the same standard code list.
> ><resp>Context and role is crucial. And the ability to reference
> >            between two codelists - eg <VehicleType> and <EmissionCode>
> >            The value selected in list #1 - effects the allowed values in
> >            list #2.  I believe that schema cannot support that.  Again
> >            OASIS CAM templates do.  And BPSS V2 allows you to
> >            provide context and role to the ebMS so that tools like
> >            CAM can inspect that and apply rules accordingly.  This
> >            is clearly an area where CAM augments schema and a
> >            simple XML parser simply is not equipped to support
> >            this extended behaviour.
> ></resp>
> > >
> > > The discussion revolved around the following points:
> > >
> > >  - Supporters of the substitution group mechanism maintain that
> > >    users need the ability to modify standard code lists in a way
> > >    that minimizes changes to the UBL document schemas in which
> > >    they are referenced.
> ><resp>Issues with versioning and cross-referencing between
> >            dependent codelists</resp>
> > >
> > >  - Opponents of the mechanism maintain that modifications to
> > >    agreed-upon standard lists should not be made invisibly, and
> > >    they observe that this problem has formerly been solved in EDI
> > >    systems simply by explicitly substituting a revised code list
> > >    for the old one.
> ><resp>Concur.  This is why we have CAM - so that "hidden"
> >          rules can be freely shared between partners in a systematic
> >          and easy to read format (simply XML scripted syntax)
> >          that can be agreed to and referenced via the CPA and
> >          stored in registry.
> ></resp>
> > >
> > >  - Supporters reply that this simple swap was possible only
> > >    because the code list schema was not itself being used to
> > >    implement validation.  Further, they claim that it is
> > >    impossible within the limits of XSD to make such a swap in UBL
> > >    without making changes to all of the schemas that reference the
> > >    revised code list.
> ><resp>Correct!  You have to *de-couple* this and prevent tight
> >  coupling - otherwise you have a maintenance and implementation
> >  nightmare.  Moving the codelists to a separate representation within
> >  registry would solve this - and then letting people use their own
> >  validation tools - such as CAM or XSLT - to resolve those.
> ></resp>
> >
> > >
> > > The TC concluded that this last point is impossible to prove
> > > one way or the other without explicit examples and that an email
> > > discussion such as this one is the appropriate medium in which to
> > > display such examples.  Three test cases were suggested:
> > >
> > >    1. Add a currency code to the standard list used in UBL
> > >       Invoice.
> > >
> > >    2. Restrict the list of currency codes accepted in a UBL
> > >       Invoice to just two values.
> > >
> > >    3. Do both (restrict the list of codes and also add some new
> > >       ones).
> > >
> ><resp> I would add the fourth case - inter-related codelists - where
> >             values selected in second codelist depend on the value(s)
> >             selected in the first codelist.
> ></resp>
> >
> > > We now turn to the business and schema experts in ubl-dev for help
> > > in exposing all sides of this problem.  Please note the following
> > > points:
> > >
> > >  - In order to provide schema validation of code list values found
> > >    in UBL instance documents, UBL provides its standard code lists
> > >    as XSD schemas in which the code values are enumerations.  For
> > >    this reason, the UBL Code List specification does not provide a
> > >    fixed schema for code lists, but rather a template for such
> > >    schemas.
> ><resp>Preferably accessible from Registry</resp>
> > >
> > >  - However, it is assumed that no actual UBL software will rely
> > >    upon schema validation alone to implement data checking; there
> > >    will always be at least one layer of logic, and probably more,
> > >    to implement business rules relating to codes (for example, a
> > >    validator can check that a country code is valid and a currency
> > >    code is valid, but it cannot check that a specific currency
> > >    code is the one that is allowed for a specific country).  So
> > >    the relative importance of code list validation itself remains
> > >    a possible question in this discussion.
> ><resp> Precisely!  The schema is there to denote the structural
> >  premutations.  More vigourous business rule driven validation
> >  engines - such as CAM - can then be used to augment schema.
> >  Providing a cheat-sheet of validation engines can then give people
> >  their implementation options - in BPSS we have
> >  XPATH, XSLT, CAM as a base set.
> ></resp>
> > >
> > >  - The discussion so far has been hindered by the lack of concrete
> > >    examples prepared by genuine W3C Schema experts.  Our greatest
> > >    need at this point is for valid examples based on the UBL 1.0
> > >    schemas that will show the actual implementation of the
> > >    strategies we've been discussing (see the test cases suggested
> > >    above).
> > >
> > > We are asking for input on the ubl-dev list in order to get the
> > > widest possible range of views on this question into the public
> > > record.  If you know of a person or group that has an interest in
> > > code lists, please point them to this discussion and ask them to
> > > subscribe.  Note again that we must stop taking input at the end
> > > of February in order to maintain the UBL 1.1 release schedule.
> > >
> ><resp> I believe we have the means to solve this without depending
> >            on W3C to cover this off - either in the short-term, or the
> >            long term - and certainly not by Feb 28th!
> ></resp>
> >
> >Thanks, DW
>