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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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