RE: [ubl-lcsc] [code lists] drafct of section to put in documentation - for comment

["Stuhec, Gunther" <gunther.stuhec@sap.com>]

Title: Message

Hello Tim,

 

the CCTS describes clearly, how we can define code lists in general (internal and external). We, in UBL have the possibility (better we have the golden opportunity) to put this definition into unambigous XML based naming and design rules. There are accepted rules from NDRSC for defining code list schemas, which are 100% conform to the CCTS.

 

This rules allows everyone to define his own codelist uniquely and everyone can use this codelists in their UBL-schemas without any modifications and restrictions.

 

The members in the UN/CEFACT ATG2 are willingness to using the same rules for defining code lists schema. If that accepted, than the most of the other groups will use this rules. Why shouldn't we go this direction, too?

 

Kind regards,

 

    Gunther

 

-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Mittwoch, 29. Oktober 2003 08:44
To: CRAWFORD, Mark
Cc: ubl-lcsc@lists.oasis-open.org; UBL Design Rules (E-mail)
Subject: Re: [ubl-lcsc] [code lists] drafct of section to put in documentation - for comment

Everyone is wholly supportive of the use of 
externally-maintained code list values in UBL.  No questions there.  
The question is *how* to incorporate externally-maintained code list values in 
UBL and the impact on import statements in the delivered UBL schema fragments. 

UBL validation incorporates the "in-use" UBL-compliant code list 
expressions found through import statements that are delivered pointing to files 
located internally to the package in the "in-use" directory. 

When these 
externally maintained code lists are in foreign code list expressions with 
non-UBL-compliant namespace URI strings, the supplied XSLT stylesheet can be 
used to read a foreign code list expression and create a UBL-compliant 
private-use code list expression for copying into the "in-use" directory to use 
during validation.  The direct use of the foreign schema expression cannot 
be easily accommodated due to a ripple effect of having to change all namespace 
URI strings in UBL to use the foreign values.  I suspect this is where the 
lines got crossed.

When these externally maintained code lists are in 
UBL-compliant code list expressions, the installer of UBL has the choice of (1) 
copying a snapshot of the code list expression into the "in-use" directory (pro: 
always available for validation; con: may not always be up-to-date); or (2) of 
editing all of the relevant UBL schema fragments to change the import statement 
to not use the "in-use" directory and to directly use the external location 
(pro: always up-to-date; cons: may not always be available for validation due to 
communication problems and requires the manually editing of the schema 
expressions to point externally instead of internally). 

Bottom line to 
this is that maintainer of code lists would be encouraged to maintain their own 
data externally from UBL - as long as it complies to the UBL schemas. 
 Otherwise we have to manipulate them to be compliant.  In which case 
they then are obviously UBL internal codes (snap shots).  Ken's concern was 
that if your intention was to hack the UBL code list mechanism for each variety 
of 3rd party code schemas it would be a nightmare.  I am pretty sure no one 
meant to say that.

We want UNCL and ISO and IMO and DISA and other 
credible organizations to work with us to create defintive codes, but we dont 
want to comprise the integrity of UBL to do so.  This strategy endorses the 
approach taken by NDR and Eve with the original code list position 
paper.

Hope that clear this up, I am sure w can (and will) discuss this 
more once we get tangible artifacts of real schemas to work with next week. 
 



CRAWFORD, Mark wrote:
> Ken,
>
> Are you stating that we would never switch from UBL code lists to externally generated code lists?  NDR was pretty specific in stating that external code lists would be used wherever available, and that any UBL generated code lists would only be used as an interim measure.
>
> Mark 
>
>
>
> > -----Original Message-----
> > From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
> > Sent: Sunday, October 26, 2003 9:37 AM
> > To: ubl-lcsc@lists.oasis-open.org
> > Subject: Re: [ubl-lcsc] [code lists] drafct of section to put in
> > documentation - for comment
> >
> >
> > At 2003-10-25 09:16 -0400, CRAWFORD, Mark wrote:
> > > An excellent first cut. I think you need to clarify hat all 
> > codes will be 
> > > handled by scheMa modules, regardless of their source so that the 
> > > necessary enumerations and their subsequent maintenance will 
> > not impact 
> > > the root schema.
> > Not sure what you mean by "impact", unless the important 
> > point you raise 
> > here is that end users mustn't ever touch the UBL schema fragments as 
> > delivered ... that they are really inviolate and can be treated as 
> > read-only documents.  I don't think that is mentioned anywhere and is 
> > something I agree should be brought out explicitly about the 
> > W3C schema 
> > expressions that are shipped.
> >
> > > I think you should also add that as external code ist owners 
> > do make their 
> > > code lists available in the form of importable schema modules, the 
> > > corresponding import statements for those code list modules will be 
> > > changed accordingly.
> > Actually, the design I put forward precludes any changes to import 
> > statements and configuration is done at the file system level 
> > through the 
> > wholesale replacement of files.  My supposition was that 
> > asking any user to 
> > edit a document was an invitation to typographical errors or 
> > incorrectly 
> > modified files that would be rendered useless and difficult 
> > to diagnose or 
> > repair ... and an easy source of complaints to the (future) UBL-dev 
> > regarding "what did I do wrong?".
> >
> > In place of editing import statements, the UBL design is 
> > hard-wired to 
> > utilize the code list definitions found in the "in-use" directory as 
> > documented by Tim:
> >
> > > From: Tim McGrath <tmcgrath@portcomm.com.au>
> > > To: ubl-lcsc@lists.oasis-open.org <ubl-lcsc@lists.oasis-open.org>
> > > Sent: Sat Oct 25 01:59:26 2003
> > > Subject: [ubl-lcsc] [code lists] drafct of section to put in 
> > documentation 
> > > - for comment
> > > ...
> > > Within the UBL schemas, an "in-use" directory is used to 
> > define each code 
> > > list to be used during the validation process. Only values 
> > for standard 
> > > definitions of code lists are validated for their content 
> > when UBL is run 
> > > out-of-the-box. All other code lists are validated using the placebo 
> > > definition merely as having a tokenized value, and this value is not 
> > > checked against any further constraints.  Customised 
> > implementations can 
> > > chose to adopt either stock or private-use code list 
> > definitions, and 
> > > after any such engagement can revert to the out-of-the-box 
> > configuration 
> > > by engaging the original standard or placebo code list definition.
> > Using this design, the sole responsibility is the wholesale 
> > replacement of 
> > the in-use definition file with the desired definition file, 
> > be it one that 
> > we've supplied or however that desired definition file may be 
> > created.  And 
> > we are supplying my XSLT stylesheet that helps in the synthesis of 
> > qualified private-use definition files.
> >
> > This wholesale replacement can be done with any 
> > file-system-level "copy" 
> > command and without editing any UBL files whatsoever that 
> > might jeopardize 
> > the integrity of the W3C schema fragments.
> >
> > I hope this addresses the concerns that you had.
> >
> > ................... Ken
> >
> > --
> > Next public European delivery:  3-day XSLT/2-day XSL-FO 2004-01-??
> > Instructor-led on-site corporate, government & user group training
> > for XSLT and XSL-FO world-wide:  please contact us for the details
> >
> > 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)
> > ISBN 0-13-065196-6                       Definitive XSLT and XPath
> > ISBN 0-13-140374-5                               Definitive XSL-FO
> > ISBN 1-894049-08-X   Practical Transformation Using XSLT and XPath
> > ISBN 1-894049-11-X               Practical Formatting Using XSL-FO
> > Member of the XML Guild of Practitioners:     http://XMLGuild.info
> > Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc
> >
> >
> > 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-lcsc/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-lcsc/members/leave_workgroup.php.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160