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

MHonArc v2.5.0b2 -->

















ubl-ndrsc message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: Tim McGrath <>
To: "CRAWFORD, Mark" <>
Date: Wed, 29 Oct 2003 15:44:27 +0800





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