Re: [ubl] A Codelist Issue

Thanks, Anne,

I obviously believe we should use the code list mechanism as proposed and following the example provided last night and as revised by Tim.

If 1.0 is released without this code list mechanism I am afraid there will be no backward compatability if it is added later. The premise of having an abstract type and an element used by reference is essential to the mechanism. The schema generation has to be revised whether this code list mechanism or the old one or any one is used.

Once this mechanism is established it will be easy for third parties to make extensible code list schemas for UBL to use. I think we want to encourage this.

In addition, this mechanism has been reviewed by the CLSC and other UBL-ers as well as leaders of OAGI, Rosettanet, and others at NIST and found to be robust and desireable. Lets take advantage of all this effort and capture it in the 1.0 version.

Marty

In a message dated 3/11/2004 5:47:31 PM Eastern Standard Time, anne.hendry@sun.com writes:

I do see a difference in these use cases. The first one is where a
standard organization that owns a standardized code list is publishing a
revision their own code list, in a public forum, and the second is where
some subset of trading partners are extending (not revivsing the whole
thing) an existing code list for their own use by leaving the existing
list in tact but adding to it their required values. What Marty is
proposing allows for our earlier notion of 'stock' (or perhaps
'private') code lists. The thing is that since Beta we have dropped
the inclusion of 'stock' and 'private' and now only supply 13 code lists
that we've defined as 'standard' ('standard' meaning that UBL defines,
owns, and requires the use of these specific values) code lists and all
the other code lists referenced in our schemas are completely open to
whatever the tps want to use - they are what we originally called
placebo, and there is no restriction on their use and no validation. We
have now a white/black situation with no gradation, and Marty's proposal
takes care of some of the in-between cases, but just to be aware that
this proposal would only apply to a very few code lists at the moment (3
maybe at most).

There is definitely support for Marty's use case (hopefully you'll hear
from Sylvia shortly about her experience in this area), and Marty's
proposal seems like it could be considered for 1.1 or 2.0, but the
reality of the situation at the moment for UBL is that since we have
removed support in the model for all of our other-than-standard code
lists, there is no need in this release to have support for this type of
extensibility - we ourselves would not be making use of it, and as I
said, it would only apply to about 3 code lists max.   I'd advocate that
we acknowledge the need for some type of feature to support Marty's
case, but that we shelve the implementation of the solution until we
can come to concensus on an appropriate one, since we do have what we
need at the moment without substitution groups to solve the code list
support we have (the 13 code lists), and then continue this discussion
to try to come to resolution in the near future on this requirement (I
do believe it is a requirement that we'll see the need to support
shortly). But this would give us more time to review the
appropriateness of substitusion groups, or come up with an appropriate
alternative - and still get 1.0 our the door.

-Anne

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?
>
>If you are saying that this would allow valid UBL instances to
>include currency codes from alien namespaces without changing the
>namespace of the instance, I believe that we are all agreed now
>that this would be a bug, not a feature. If instances are going
>to be coming into my system that have unexpected currency codes,
>then I want those instances to carry a namespace that tells me up
>front that they have data structures that my system doesn't know
>how to handle.
>
>(Bear in mind that I am not an XSD guru, so if I'm missing
>something here, let me know.)
>
>Jon
>
>   From: Burnsmarty@aol.com
>   Date: Thu, 11 Mar 2004 16:05:12 EST
>
>   In a message dated 3/11/2004 3:48:10 PM Eastern Standard Time,
>   jon.bosak@sun.com writes:
>
>   | By requiring a user or group of users to only define their
>   | differences and use unaltered UBL and third party code lists, for
>   | that matter, we facilitate a robust application of the technology
>   | and an evolutionary path forward.
>
>   I'm not seeing the big advantage here over just deciding to use a
>   revised code list schema.
>
>   Let's say that we've agreed to use BSI currency codes, and now BSI
>   adds a new one (as they did a few years ago with the euro). Now
>   we need to agree that we need to support the new value -- that's
>   some committee meetings right there -- and then we need to revise
>   our currency schema to validate "euro," and then we also need to
>   revise all of our software to process euros (which is *not*
>   accomplished simply by revising the schemas to validate "euro" --
>   quite the opposite, in fact). In light of all this, what's the
>   incremental work saved by using the substitution group mechanism
>   over just agreeing to use an updated version of the currency code
>   list schema?
>
>   Jon
>   Jon,
>
>   Substitution groups are not trying to address this use case which I think
>   would procede as you describe.
>
>   Now, however, let us say we have produced UBL 1.1 and IBM wants to make an
>   agreement with its suppliers to use ubl and wants to enable "IBM" bucks as a
>   currency. They would be able to do so by defining the IBM namespace, import the
>   UBL namespace(s) and define their own schema extension as follows (fragment
>   shown):
>
>   |-----------------------------------------------------------------------------
>   ---------------
>
> <xs:element name="CurrencyCode" substitutionGroup="cur:CurrencyCodeA">
>    <xs:complexType>
> <xs:simpleContent>
>    <xs:extension base="CurrencyCodeContentType">
> <xs:attribute name="codeListID" type="xs:normalizedString" fixed="IBM"/>
> <xs:attribute name="codeListAgencyID" type="xs:token" fixed="0"/>
> <xs:attribute name="codeListVersionID" type="xs:string" fixed="0000f"/>
>    </xs:extension>
> </xs:simpleContent>
>    </xs:complexType>
> </xs:element>
>
> <xs:simpleType name="CurrencyCodeContentType">
>    <xs:union memberTypes="iso4217:CurrencyCodeContentType">
> <xs:simpleType>
>    <xs:restriction base="xs:normalizedString">
> <xs:enumeration value="IBM"/>
>    </xs:restriction>
> </xs:simpleType>
>    </xs:union>
> </xs:simpleType>
>
>
>   |-----------------------------------------------------------------------------
>   ---------------
>
>   With this definition, instance documents could use the following anywhere in
>   the ubl schemas cur:CurrencyCode was used:
>
>   <ibm:CurrencyCode>IBM</ibm:CurrencyCode>
>
>   |-----------------------------------------------------------------------------
>   ---------------
>
>   Marty
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
>
>

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.

ubl message