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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Code list extensibility and substitution groups


Thanks for you note, David.  You may have missed my point.  I said I
wasn't all that convinced code value constraint or extension was
necessary anywhere other than in the application.  If I were afraid of a
"rat's nest of schema and overrides," it's safe to say adding another
complex layer of standards, like CAM, to the whole mess doesn't make it
any more desirable!

If I absolutely felt compelled to use schema to enforce a restriction of
currency codes to Euros, Dollars and Pounds, then I can make do using
"redefine."  I have an example Purchase Order at
http://www.novannet.com/cd-UBL-1.0/xml/office/UBL-Order-1.0-Office-Example-with-Bad-Currency.xml
which uses an "override" of the UBL Order-1.0 schema.  The "override" PO
Schema, UBL-Order-1.0-Novannet.xsd, merely brings in my own currency
list, UBL-CodeList-CurrencyCode-1.0.-Hard.xsd, in addition to the base
UBL Order-1.0 schema.  In turn, my currency schema simply redefines the
standard UBL currency list to include only those three currency codes of
interest (EUR, GBP and USD).  When you bring my sample
UBL-Order-1.0-Office-Example-with-Bad-Currency.xml into XMLSpy and
validate it, the "bad" currency of Canadian Dollars (CAD) is duly noted.

For such a small example, this doesn't seem like much of a "rat's-nest."
Two small schema are used in addition to all the standard UBL 1.0
infrastructure.  Using "redefine" in this way avoids the need to change
any UBL document schemas at all.  I haven't tried any analogs using the
substitution group mechanism, but I imagine it can be made to work the
same way.

Nonetheless, I would still probably prefer to refer to the "virgin" UBL
document schema in my instance data - with no subsetting or extension of
standard code lists - and let my application do the validation for
particular currencies that I actually support - i.e., move the business
logic into the one place it makes sense: my application.

William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320

----- Original Message ----- 
From: "David Webber (XML)" <david@drrw.info>
To: "William J. Kammerer" <wkammerer@novannet.com>;
<ubl-dev@lists.oasis-open.org>
Sent: Friday, 18 February, 2005 09:41 AM
Subject: Re: [ubl-dev] Code list extensibility and substitution groups


William,

Well put clarifications. I'm looking to paraphrase this here - if the
schema contains the "all possible results set" - in terms of both the
structure and the allowed values - then you can use tools like CAM to
augment the schema and serve as the business agreement rules - that
enforce the deltas.

Ideally in an ebXML world this goes from the BPSS step that is
identifying a business transaction document (in our case the UBL
transaction) - with a context conditional of - majorCurrencyOnly - to
the CPA agreement on service/actions between partners, to the ebXML
envelope, that the ebMS then recognizes, and references the CPA isntance
in the Registry - that then tells it that the validation script for that
document type is the CAM template.

As you point out - this avoids getting tangled in schema mechanics that
are almost certain to be hard to diagnose or implement - and puts the
logic where it needs to be as part of the business agreement layer -
using the CAM template to capture that context and detail.


Thanks, DW


----- Original Message ----- 
From: "William J. Kammerer" <wkammerer@novannet.com>
To: <ubl-dev@lists.oasis-open.org>
Sent: Friday, 18 February, 2005 08:15 AM
Subject: Re: [ubl-dev] Code list extensibility and substitution groups


I'm not going to outright disagree with my good friend David RRR Webber
(I've promoted him to have 3 middle initials, 2 short of the future
King). But I'm not sure "ad hoc extensibility of standard code lists
[is] really a requirement."

Putting aside versioning, if a value is constrained to contain an ISO
4217 currency code, then I rightfully assume any of its values can be
used to form a valid document, for example. Now, it may be a business
requirement that the supplier only accepts prices in USD and EUR, but it
would be truly frustrating to have my XML tools or translator bark at me
because I used GBP - what to me appears to be a perfectly sound, hard
currency. It would be hard to trace back through the rat's nest of
schema and overrides to see just why this is happening - why a valid ISO
4217 code is causing me conniptions. IF IT'S A PAROCHIAL BUSINESS
REQUIREMENT, THEN SCHEMA DO NOT SEEM TO BE THE APPROPRIATE PLACE TO HIDE
THE REQUIREMENT. I guess I'd rather see the requirement that only
Dollars and Euros are used by my trading partner within an ancillary
piece of documentation - or even in a response message saying "I
expected only EUR and USD."

On the other hand, code value restriction might have found a place in
X12 and EDIFACT EDI implementation guidelines because codes were used
all over the place to do things names are used for in XML - e.g., to
differentiate delivery dates. The only way you could make the DTM
segment make sense is if you "restricted" (in the printed guideline) the
code value list to the 2 or 3 sensible values out of an EDIFACT codelist
containing hundreds. But a Delivery core component gives you only those
"Delivery" dates that make sense in that context, e.g.,
ActualDeliveryDateTime and RequestedDeliveryDateTime. There's certainly
no need for code restriction in UBL to differentiate Delivery dates,
because there are no codes - only element names. But that's the primary
reason folks restricted code lists in EDI; why does it have to be
carried over to core components and XML?

William J. Kammerer
Novannet
Columbus, OH 43221-3859 . USA
+1 (614) 487-0320



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