Re: Code Lists (for Atlantic call if possible) was Re: [ubl]NDR Codelist Example

[Tim McGrath <tmcgrath@portcomm.com.au>]

having seen Ken and Syliva's comemnts I think we are in  agreement.  just a confusion between ATG defined codes and no-ATG defined codes.  I have no issue with ATG defined codes - they are out of our control.  we should be getting those from ATG (or the CEFACT ICG group). therefore our NDRs have nothing to say about them.

my comments only relate to UBL defined codes - many of which are new to UBL 2.0.

Tim McGrath wrote:

unfortunately i cannot hold out for the Atlantic call tonight but i do think we need to get this straight.  as we try to finalize things, starting to put the pieces together, we need to understand how all the threads connect.  This means the NDR, schemas and the code list approach have to support each other.

i agree with Ken, i thought we had made a decision to use external /second-phase validation (ie. genericode) for enumerations and not mandate any methodology (e.g. W3C Schema, Schematron or XSLT).  if UBL 2.0 has the UBL1.0 code list schemas complete with enumerations then i dont see how we can also have a genericode offering as well.  if GEFEG users feel the need to continue with the 1.0 methodology then i am not sure this is a problem. they can achieve this with a supplementary, second-phase validation schema.

perhaps to move ahead with this issue we need to build an end-to-end example to show what we think the mechanisms should be. i know Ken did this but now was can use real UBL 2.0 examples. I suggest we take one UBL 2.0 code list and show:
a. the spreadsheet entries
b. the UBL 2.0 schema(s) view
c. the genericode file for validations
- and that's it. 

i will volunteer for (a) and (c) but may need help with (b).  once we have this we can have a more informed discussion about the implications of all this.  then we write the NDRs that support this approach.

Sylvia Webb wrote:

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 




---------------------------------------------------------------------
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 

  

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath