[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]