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] NDR Codelist Example


At 2006-06-07 13:18 +0800, Tim McGrath wrote:
>are you sure we can have both?

My project focus has been elsewhere lately, so I posted a few weeks 
ago (copied below) that there can be no enumerations for code lists 
other than the ones adopted from ATG ... I think there are three of those.

>Sylvia Webb wrote:
>>
>>
>>
>>
>>The TC agreed that we would not hard wire the genericode 
>>methodology into the standard. This means that we still need rules 
>>to support the 1.0 code list methodology.

I do not make the same connection, Sylvia ... here are the minutes:

At 2006-02-28 16:35 -0800, jon.bosak@sun.com wrote:
>MINUTES OF PACIFIC UBL TC MEETING
>00H30 - 02H30 UTC TUESDAY 28 FEBRUARY 2006
>
>ATTENDANCE
>
>    Jon Bosak (chair)
>    Stephen Green
>    G. Ken Holman
>    Tim McGrath (vice chair)
>    Andy Schoka
>    Kumar Sivaraman
>    Sylvia Webb
>...
>    Team report: Code Lists
>
>       GKH: TonyC is back from vacation; an assumption about empty
>       genericode instances turns out to be incorrect, and am now
>       working out a way around that.
>
>       SW: We have been getting questions about code lists.  Some
>       companies cannot implement the new Code List Methodology;
>       they will use the same method of code list checking that
>       they use for EDI and want to know if this is a
>       customization.
>
>       JB: In other words, their software can't apply different
>       code list subsets to different document contexts, and they
>       want to know whether it's still UBL 2.0 compliant?
>
>       SW: Yes.
>
>       JB/GKH/SG: "UBL 2.0 compliance" means compliance to the UBL
>       2.0 schemas.  Since we externalize most code value checking
>       in 2.0, any method of code value checking is "UBL 2.0
>       compliant."  The Code List Methodology will be a separate
>       specification that can be applied to any set of schemas, not
>       just UBL.  So they will not be "UBL Code List Methodology
>       compliant" but they will be "UBL 2.0 compliant."
>
>       SG: There may be a concern about compliance with the UBL 2.0
>       NDRs.
>
>       JB: Only if they are designing their own schemas and
>       referencing UBL 2.0 NDR as a separate specification.
>       Obviously they can't be using our schemas and be in conflict
>       with our NDRs (unless we've made a mistake).
>
>       AGREED: We need to make sure that mandatory support for the
>       UBL Code List Methodology is not hardwired into the UBL 2.0
>       NDRs.

We only agreed not to make use of the methodology *mandatory* in the 
UBL 2.0 NDRs ... we did not agree to that the NDRs wouldn't support 
the methodology.  I don't see anything there in that discussion that 
says we are obliged to continue to support the 1.0 methodology, and 
indeed we cannot because that would have enumerations in the schemas.

If there was something more specific implicit in that resolution, 
then the resolution was not understood by myself and perhaps others 
present.  I certainly would not have agreed to leave the 1.0 
enumeration approach in the schemas since it prevents *any* other 
method of validating the values from being implemented.  Not making 
it mandatory is different than preventing its use.

The discussion went way back to the Ottawa face-to-face when the 
committee decided to explore alternative approaches, making UBL 2 
more usable in scenarios where UBL 1 approaches to code lists were 
too restrictive.  That was acted on and delivered and, in February, 
not made mandatory but it was also still supported, thus the NDR 
should support it.

. . . . . . . . . Ken

At 2006-05-26 02:25 +0200, I wrote:
>At 2006-05-25 22:04 -0700, Sylvia Webb wrote:
>>Please do not forget that we agreed in the 28 February UBL Pacific call that
>>the UBL Codelist Methodology is an additional specification
>>(http://lists.oasis-open.org/archives/ubl/200602/msg00115.html).
>>
>>This means that we need to provide values for codes as we did for UBL 1.0
>>independent of what is needed for the new Codelist Methodology. Ideally,
>>these values should be available for the next round of schema generation.
>
>My understanding is the code list values will not be going into the 
>schemas.  The schema expressions for every code list other than the 
>three ATG code lists we are using will be the generic wild card 
>allowing any value (I cannot remember off hand if the values were 
>tokens or normalized strings).
>
>While the code list methodology is a separate specification, and the 
>code list values themselves are yet another deliverable, the schemas 
>need to be structured in order to support the use of those specifications.
>
>. . . . . . . . . Ken


--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSL-FO/XSLT/XML training:    Birmingham, UK 2006-07-04/13
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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