UMM, modeling and alignment (was Example RN PIP 3A4)

[James Bryce Clark <jbc@lawyer.com>]

JJ, your comment is an excellent and important point.  

For now we have deliberately kept the BPSS object model open, with a
variety of alignment paths at the expense of simplicity.   

XPath probably facilitates half-hearted partial adoption of ebXML business
processes by some, and may be misused by others.   The risk is that some
legacy users, or legacy-driven vendors, will make the minimal alignment and
them re-freeze themselves at a low level of interoperability.   I don't
think that is avoidable;  we must facilitate wide adoption.   XPath plays a
useful role there.   My hope is that the upgrade path to logically modelled
transactions will exert an upward pull on users, once they dip their feet
in the pool.  

UMM/UML expressions of reusable transactions are the "bait" for this
upgrade path to greater interoperability.   I think that is why so many of
us strongly support ebXML's bias towards modelling and UMM.  That metamodel
is not perfect, but it's pretty good, reasonably vendor-neutral, in use in
commerce, and within reach.   

After Vienna one of our continuing projects for discussion should be a set
of best practices for use of the specs, that nudge people in that "right"
direction. 

Our job is to be the good guys in e-commerce.   After we crack open a few
bottles of Gewurztrammer this week, the next order of business is to blow a
bunch of attractive, reusable business processes and components into
repositories, make them discoverable through logical expression, and see if
the world bites.     

Best regards    Jamie

- - -
James Bryce Clark
Spolin Silverman & Cohen LLP 
310 586 2404    jbc@lawyer.com    

At 07:55 AM 5/7/2001,  Jean-Jacques Dubray wrote:
>Kurt:
>
>Thanks for this great work.
>
>I would like to emphasize one point: we should avoid using XPath
> expression on the message document because this makes 
>collaborations much less reusable across standards. I understand
>that this is not feasible in the case of RN but moving forward, a good 
>design principle would be to use distinct document formats to 
>express different intend. The binding at the format level would 
>happen in the DocumentSpecification.
>
>This might look like a little step one way or the other, however, 
>converging at the "business collaboration" level is even more 
>important than converging at the format level. Formats can most 
>often be mapped to each other, it can quickly become un-
>manageable to map and adapt business processes to a slew of 
>nearly identical collaborations. Once a collaboration is in place an
>agreed upon by an industry or an eco-system, it is relatively simple to
>manage N different document formats flowing through the same 
>infrastructure as they are nicely decoupled from each other.
>
>Jean-Jacques Dubray, Chief Architect
>eXcelon Corp.
>
>-----Original Message-----
>From: Kanaskie, Kurt A (Kurt) [mailto:kkanaskie@lucent.com]
>Sent: Friday, May 04, 2001 12:51 PM
>To: 'ebxml-bp@lists.ebxml.org'
>Cc: 'ebxml-ccbp-analysis (E-mail)'; 'ebXML-PoC'
>Subject: Example RN PIP 3A4 in BPSS
>
>Attached is an ebXML Business Process Specification XML 
>document for RosettaNet PIP 3A4 version 1.4 that I did as a personal 
>POC.    I think it is correct, but if someone finds a mistake or I left 
>something out, please let me know. Some interesting points:
> * Use of Packages to represent Cluster, Segment and PIP
> * Use of guardExpression and XPath to determine the response 
>  type, since RosettaNet uses the same message for both positive 
>  and negative responses.
> * Use of XPath to reference other elements.
> * Only 74 lines of XML for the entire PIP!

* * *