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


William,

Been there done that argument.

You can download jCAM from http://www.jcam.org.uk

It's fully functional and works out-the-box today.  It's open
source.

It is integrated with Hermes ebMS and CDC PHIN ebMS
and Cyclone Commerce Integrator software packages.
It has been verified by NIH on a USGov PoC project.
You can download the code and documentation for this
and use it today - as part of a solution you can package
for SMEs - http://ebxmlbook.com/interop .

The role and variable mechanism that is part of BPSS V2
can be used directly with CAM templates.

The OASIS specification is ready to go to public approval
process.

This is already way more than you can do with any other
tool set available.

DW

----- Original Message ----- 
From: "William J. Kammerer" <wkammerer@novannet.com>
To: <ubl-dev@lists.oasis-open.org>
Sent: Sunday, February 20, 2005 9:21 PM
Subject: Re: [ubl-dev] Code list extensibility and substitution groups


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




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