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


The current NDR does support the new codelist methodology. This is not the
question.

As I stated in Ottawa and in February, GEFEG received substantial feedback
that UBL users need to continue to use the UBL 1.0 codelist methodology,
regardless of any opinions about that methodology. This means that as an
option, the NDR need to continue to include existing portions of Section 6.

Possibly Section 6 needs additional clarification, but, this should not mean
deleting the previous rules.

Sylvia
-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Wednesday, June 07, 2006 4:12 AM
To: ubl@lists.oasis-open.org
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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 





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