Re: [ubl-dev] UBL's role

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

Sylvia,

The Hermes ebMS supports CAM using the jCAM open source processor
and source code and Java components for this direct integration is
freely available from SourceForge.

Also the jCAM has been tested with Cyclone Commerce Interchange
family of products and the source code for that is also available as
open source.

In addition jCAM works with the CDC PHIM ebMS solution too.

There are some sample UBL templates available from the CAM OASIS
site - and in any case - any implementer can rapidly adapt their own
solution to include jCAM as either a direct servlet or a webservice
call to support UBL in their environments.  Accountis are one such
that have done working on using CAM with their product.

The CAM specification is an OASIS specification, and compared
to Schematron there are many advantages:

1) CAM is much more ebXML aware, and CCTS aware with
    direct support notions such as BIE, CC, ABIE, etc.
2) CAM supports CCTS style context statements and
     dynamic context driven validation and assembly
3) CAM is ebXML registry aware and able to support
    noun dictionaries - such as a CCTS dictionary.
4) CAM templates are much more concise than Schematron
    (about 1/4th the size on a typical equivalent template).
5) CAM templates can generate output formatting.
6) CAM templates can generate automatic error reporting
    in either XML or HTML formats integrated inside
    the message transport (see Hermes implementation).
7) CAM templates can integrate with BPSS V2 and
    share context statements across BTAs and ebMS
    delivery.
8) jCAM implementation is DOM called via DOM pointers.

I'll stop here - the bottom line is that we developed CAM
after we examined Schematron and determined its weaknesses
from a eBusiness perspective.

Let me know if there are specific things not covered above
that you might be looking for?

Thanks, DW


----- Original Message ----- 
From: "Sylvia Webb" <swebb@gefeg.com>
To: "'David Webber (XML)'" <david@drrw.info>
Cc: <ubl-dev@lists.oasis-open.org>
Sent: Monday, January 10, 2005 3:27 PM
Subject: RE: [ubl-dev] UBL's role


David,
Can you provide us with a list of commercially available business apps like
ERP software or Accounting packages that support CAM?
What are the benefits of using CAM instead of Schematron which is an ISO
standard?


Sylvia Webb
-----Original Message-----
From: David Webber (XML) [mailto:david@drrw.info]
Sent: Monday, January 10, 2005 12:15 PM
To: Duane Nickull; Juha Ikävalko
Cc: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] UBL's role

Duane,

How many of these "scenarios" have you implemented?

----- Original Message ----- >
> Not sure what CAM adds in this scenario since XML schema can handle
> most of what is needed for UBL.
>
> Duane
>

So what about the "most" - what do you do when UBL cannot handle it?  What
is Plan B?

Juha IMHO correctly identifies and understands that XSD schema has only a
very limited ability to express structural permutations and layouts.
It also has no ability to share definitions through a central registry
facilities and to version those definitions across a community; none, zero,
nahdah.

This is the premise that the W3C started with five years ago.  It assumes
there is only one, or at most two or three permutation of structures for a
schema along with limited to none interdependencies between fields.

Simple ticket like structures may fall into this category - and certainly
document-style forms (memo's, faxes, letters) but business transactions
rapidly require way more integrity checks than schema provides.
(e.g. if field A1 contain value Y, then B1, C1, D2 may only contain these
values, and field E3 is not required).

Not only that - but as the number of partners increases - its a classic know
fact that the number of these permutations jumps accordingly.

So - by augmenting XSD with tools like CAM where you can declaratively state
these business rules, and manage them by context, and business process step,

then you can implement a real live system dynamically using XML templates to
drive it.

The situation today on the ground is that all these rules are "hidden" in
Word docs or spreadsheet docs - that implementers somehow have to code into
Java programs behind the messaging services.  And then recompile that code
when new partners or scenarios emerge.  This is good for programmer
employment, but bad for business services and efficiency.

As we have shown - this is now replaced - by integrating jCAM directly with
Hermes ebMS - so the messaging services can perform a complete range of
content handling and routing services dynamically driven by XML templates.
And those templates can be referenced from a collaboration registry.

EDI tried the "one message size fits all" approach for twenty plus years -
and even the UBL EDI-lite (that UBL was derived from), while this may have
some advantages - there is no getting away from the need for CAM in these
scenarios at multiple levels.
And not having a registry hobbles your ability to service a community with
runtime level services.

You can try the 3 monkeys, hear no, see no, speak no, approach, but you
cannot fool implementers in the field to the real needs.

Cheers, DW