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

["William J. Kammerer" <wkammerer@novannet.com>]

DW, there's an immediate problem - code subsetting and extension - to
solve (if it even needs solving) before the end of the month. So there
probably isn't enough time to worry about CAM. That aside, what "serious
tools [does CAM] bring to enable context driven rule management"? CAM is
just a draft specification, isn't it? Have any ERP vendors indicated
support for it?  With all due respect, if CAM were such a "serious
tool," why are you the only one yapping about it?

Let's retain focus.  I could actually be wrong, and perhaps there really
is a need for UBL's Requirement 26 for Code List Extensibility. Maybe
existing commercial off-the-shelf packages for SMEs don't support
modifying, restricting or extending codes in their application(s). Then
we'd need a schema-centric solution, simply because the solution can't
be pushed into the application. Additionally, SMEs don't have the
resources to implement multiple layers of the ebXML stack, with CAM
thrown in for good measure.  This requires that a solution to
Requirement 26 be useable entirely within (the context of) UBL schema.

And whatever does "on-boarding" have to do with code lists?  Honestly,
David, are we speaking the same language?

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: Sunday, 20 February, 2005 06:12 PM
Subject: Re: [ubl-dev] Code list extensibility and substitution groups


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, 20 February, 2005 01: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