[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL's role
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]