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

["David Webber \(XML\)" <david@drrw.info>]

William,

You are making the same arguments as support the use of
CAM, and then overlooking some key issues that you
conveniently pass over - aka giant gaps!

Firstly - I disagree that this stuff belongs in the backend
applications.  That is *exactly* what has dogged EDI all
these years - that people have proprietary extensions that
are hidden in the backend and completely inflexible /
unknown to the rest of the participants.

The whole goal here is to support easier integration and
on-boarding - not create yet more "gotchas".  With UBL
there should be less to worry about.  Notice you cannot
do pre-transmission testing if all the logic is buried on
someones backend system somewhere.

And that brings us to the second point - the need for
XML scripting is driven by the need to support
context.  You do not get context support in schema.
Instead your "small" override schema becomes someone
elses small override schema, and someone elses, and
before you know it - you are managing a whole raft of
these without any control mechanism.

Enter ebXML.

The CPA defines the collaboration and
the service / action pairs, associated with that is the
transactions (UBL) and then associated with that is
a CAM template and context parameters.  On the
ebXML envelope you can set your CPAid and your
service/action pair.  The receiving ebMS can then
lookup the CPA for that CPAid - and apply the
CAM template it specifies - for the context
provided - and that will use the business rules to
guide the codelist selections needed.  One schema,
one CAM template, one CPA template.  All of
which can be agreed to by the parties concerned.

This also works for WS-* and WSDL - but in
that case you follow WS-I and have one WSDL
per transaction type - and the CAM template can
then have a one-to-one correspondence (it can
lookup context directly from the inbound XML
if needed via an XPath expression defined in the
CAM template header).

Notice this also supports loosely-coupled connections
since the processing is being controlled by scripting
and not backend program modules.

I'm not saying this invalidates your small-scale
technique.  I think we have to be clear here that
understanding the deployment model is vital.
If I'm building a one-off setup for two or three
partners - what you have may be just fine.

If I'm creating an exchange system for a government
agency with hundreds of submissions, or an
e-marketplace setup with hundreds of suppliers -
then you need the serious tools that CAM can
bring to enable context driven rule management.

Cheers, DW

----- Original Message ----- 
From: "William J. Kammerer" <wkammerer@novannet.com>
To: <ubl-dev@lists.oasis-open.org>
Sent: Sunday, February 20, 2005 1:43 PM
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
>
>
>