OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Thanks Mark for continuing this dialogue to help me better understand what 
is expected in UBL.

At 2003-10-27 08:04 -0500, CRAWFORD, Mark wrote:
>Are you stating that we would never switch from UBL code lists to 
>externally generated code lists?

"Never" is a blanket word, but looking at the namespace declarations it was 
my gut feel that "foreign" code lists could not (ever?) be plug-and-play.

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

Did the specificity apply to "external code list *expressions*" or 
"external code list *values*"?  I believe the distinction is critical.

The stylesheet I developed for creating private-use UBL-compliant code list 
expressions from sets of foreign code list values provides plug-and-play 
integration through the operating system copy facility as described in my 
earlier note, not necessitating any editing of any UBL schema expressions 
thereby not jeopardizing the integrity of the schema documents.

If, however, one anticipates plugging in foreign code list expressions into 
UBL by editing the import statement to bring in that expression verbatim 
(many expressions are or should be read-only since they are under the 
purview of other organizations), there would be (I think) a tremendous 
ripple effect.

Let's consider the UN Currency Codes as an example:  I think choosing to 
use the external code list expression would change the data type for the 
currency value to be in the 
namespace 
http://www.unece.org/etrades/unedocs/repository/codelists/xml/CurrencyCode.xsd 
which would then require a (manual?) edit to each of 
UBL-CoreComponentParameters.xsd and UBL-Reusable.xsd, UBL-Invoice.xsd, 
UBL-Order.xsd, UBL-OrderChange.xsd and UBL-OrderResponse.xsd.

Unless I'm mistaken the opportunity for jeopardizing the integrity of the 
schemas is immense when needing to do as much hand-editing as described 
above ... and it would have to be done by all parties involved in the 
interchange of validated documents.

However, my proposed methodology of (1) synthesizing 
UBL-namespace-conformant code list expressions from a combination of an 
already-conformant placebo expression plus the values extracted from a 
foreign code list expression, and (2) wholesale copy of the desired UBL 
code list expression in place of the in-use code list expression, will 
require zero edits to any UBL schema expressions.  This would also insulate 
the suite of UBL schema fragments from externally triggered changes in 
foreign code list expressions that might be unexpected and out of sync 
between two parties using UBL: say the UN currency codes were changed by 
the UN and all of the schemas then pointing to the foreign expression were 
rendered un-validatable until a continuing set of manual adjustments were 
made by all parties involved.

Perhaps this helps understand my own perspective and my own understanding 
of the influence of namespace URI strings utilized in the UBL 
environment.  Unless I'm missing something important, sanitizing the values 
found in foreign code list expressions to be compatible UBL expressions 
will be critically important to a sustainable and maintainable deployment.

I would welcome any clarification I need to see to better understand the 
issues as my advice has been based on the assumptions noted above.  If I'm 
wrong I need to be corrected.

Thanks again, Mark!

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]