Re: [ubl-dev] UBL's role

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

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