[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-lcsc] [code lists] draft of section to put in documentation - for comment
Best Regards
Stig Korsgaard
M.Sc.E Standardisation Manager
Tel:
+45 3370 1083
Cell: +45
2121 8234
Mail:
stk@finansraadet.dk
Danish Bankers
Association
Amaliegade
7
DK-1256 Copenhagen K
Tel: 3370
1000
Fax:
3393 0260
mail@finansraadet.dk
www.finansraadet.dk
-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: 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 allcodes will behandled by scheMa modules, regardless of their source so that the necessary enumerations and their subsequent maintenance willnot impactthe 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 ownersdo make theircode 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 indocumentation- for comment ... Within the UBL schemas, an "in-use" directory is used todefine each codelist to be used during the validation process. Only valuesfor standarddefinitions of code lists are validated for their contentwhen UBL is runout-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. Customisedimplementations canchose to adopt either stock or private-use code listdefinitions, andafter any such engagement can revert to the out-of-the-boxconfigurationby 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]