Re: BPSS Strategic issue: one and only one metamodel

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Jim,
Please be specific.
What exactly needs to be changed?
You agreed yourself to leave it as is, right before we submitted previous
time, but if we have new information from the legal community, then we should
change it now.

As to Bob's two issues D. and E.:

D: timeToAcknowledgeAcceptance has not been moved. It reflects exactly where
it is in UMM as per N90.91. So in this case UMM does not conform with the
three cited sources of rules for legally binding electronic commerce! I am
fine with changing BOTH UMM and Specification Schema to whatever the Lawyers
determine is the correct placement.

E: isNonRepudiationOfReceipt is indeed different in UMM N90.91 and
SpecSchema,v.99. We agreed as per v.99 that it would be reasonable to allow
the responder to request a signed receipt as well. If that is not legally
desirable, I agree we should move it to be on request only.

Part of the ongoing confusion about these parameters is that they are
associated with "activities", where they really should be associated with
document flows:

Requesting DocumentFlow:  
     timeToAcknowledgeReceipt means must receive rcptAck to this docFlow
within specified time
     timeToAcknowledge means must receive acceptAck to this docFlow within
specified time
     isAuthorizationRequired means responder must validate requestor against
authorized list
     isNonRepudiationRequired means requestor and responder must both save a
copy
     isNonRepudiationOfReceipt required means must receive signed rcptAck
     isIntelligibleCheckRequired means rcptAck implies validation

Responding DocumentFlow:  
     timeToAcknowledgeReceipt means must receive rcptAck to this docFlow
within specified time
     isAuthorizationRequired means requestor must validate responder against
authorized list
     isNonRepudiationRequired means requestor and responder must both save a
copy
     isIntelligibleCheckRequired means rcptAck implies validation

Is this the correct distribution of parameters?

There is one more difference N90.91 to SpecSchema,v0.99: 
timeToPerform is in BusinessAction in N90.91. I thought we had agreed that
that is a transaction level parameter.

-karsten

>
>
>Karsten Riemer wrote:
>
>> Bob,
>>
>> I agree fully that ebXML must support the three cited sources of rules
>> for legally binding electronic commerce.
>>
>> I disagree, however, with the implication that SpecSchema v0.99 does not
>> support these rules.
>
>I wish this woulod be true, however the issues that Bob Raises is correct.
>The BP
>Spec does not comply with the referenced documents and if we do not bring it
>in
>alignment, those who use the BP Spec in the future will find problems when
>using
>them in open trade markets.
>I have reviewed this with one of my trade lawyers associated with E2open and
>Bob's
>understanding is currect. As the BPSpec stands now I will not be able to use
>it in
>E2open because of the nature of our business.
>
>>
>
>>
>>
>> To your five lettered issues:
>>
>> A) Lines 420-421
>> This issue is as far as I can see about the text of the document only.
>> The SpecSchema model itself does support the full transaction model.
>> If you feel that is not the case, please point out where the model itself
>> falls short.
>>
>> B) Lines 1672, 2385
>> The "isSuccess" flag is not the only way of determining transaction
>success.
>> The full transaction semantics are supported, all signals, flow of
>control,
>> and associated success and failure. The "isSuccess" flag is merely a
>> convenient way of quickly looking at a DocumentFlow and knowing whether to
>> interpret it as a successful response or not. Again, if you see
>shortcomings
>> with the model  itself, please point out where the model itself falls
>short.
>
>This flag MUST go away.
>
>>
>>
>> C) Lines 527-528 (figure 5)
>> I am open to discussion of re-introduction of Document Envelope. However,
>its
>> absense does not in any way prevent implementation of multi-hop or
>brokered
>> solutions. The document flow models the information 'bundle' that goes
>from
>> the requestor to the responder (and vice versa). If that bundle does not
>> change during a multi-hop or brokered model, then you do not need to model
>it.
>> If it does change, then you do not have a simple multi-hop, you have a
>> multi-party, and need to model it as such.
>>
>> D) Line 586, 1046-1047, 1215, 2529, 2553
>> These parameters were left at BusinessAction level by agreement with Jim
>> Clark. Having them there allows for a more flexible model, but does not
>> prevent practitioners from sticking with current UMM constraints.
>>
>> E) Lines 1601, 2527, 2551
>> Same comment as D) above.
>>
>> Now a couple of questions/concerns with the statements about process
>focus.
>>
>> 1. UMM allows you to model the requesting and responding activities, but
>has
>> no  semantics about what each activity actually does or what it results
>in.
>> Therefore I do not understand how a model that names a requesting and
>> responding activity explicitly is richer than one that only implies them
>> through roles. I understand that REA is a way that we could express results
>of
>> a transaction, but we all agreed under your guidance to table that for
>future
>> versions.
>>
>> 2. UMM specifies a transaction as two activities in an activity diagram,
>with
>> object flows from requesting to responding and optionally back to
>requesting.
>> Does that not create an eternal loop activity diagram? I don't know if it
>> actually violates UML rules, but it certainly is an unorthodox use of an
>> activity diagram.
>>
>> Thanks,
>> -karsten
>>
>> >This is the discussion of one of the three strategic issues
>> >with the ebXML Business Process Specification Schema V0.99
>> >that I believe are highest priority for ebXML BP right now.
>> >
>> >1. One and only one metamodel.
>> >
>> >    The firm agreement I seek is that the BPSS must be
>> >    a strict subset of the UMM Metamodel, so that
>> >    BPSS-compliant XML runtime business process specifications
>> >    may be derived from UML models that conform to the UMM
>> >    Metamodel.  In other words, we need one and only one
>> >    metamodel. This is an issue of conceptual integrity so
>> >    everything fits together smoothly.
>> >
>> ><Tim McGrath>
>> >the Quality Review team are concerned about the weak alignment of some of
>> >these
>> >documents with the ebXML Specification Schema.  In many cases they either
>> >fail to
>> >differentiate or clearly specify the relationship between the UMM
>Metamodel
>> >and the
>> >Business Process Specification Schema.
>> >
>> >We are concerned that the confusion these current documents may spawn
>within
>> >the wider
>> >community will be damaging to the overall ebXML initiative.  For example,
>it
>> >is
>> >perceivable that these documents could result in development of UMM
>Metamodel
>> >compliant
>> >business process models, but not ebXML compliant models.
>> ></Tim McGrath>
>> >
>> >Why does the QR team have this perception, when the following
>> >statement should settle the confusion:
>> >
>> ><Specification Schema 0.99>
>> >Lines 314-319:
>> >The UML Specification Schema is a semantic subset of the metamodel behind
>> >UMM as specified in UN/CEFACT TMWG's N90, expressed as a standalone
>> >UML profile. The UML Specification Schema will through the application of
>> >production rules produce an XML Specification Document is analytically,
>> >semantically and functionally equivalent to one arrived at by modeling
>the
>> >same
>> >subset through the use of UMM and its associated production rules.
>> ></Specification Schema 0.99>
>> >
>> >Is it because there actually are easily-detectable differences, such that
>> >the Business Process Editor developers are asking me off-line how
>> >to resolve them?
>> >
>> >Why is this important?
>> >
>> >1. UMM is mandatory for modeling in ebXML.
>> >From the approved ebXML Technical Architecture Specification v1.0.4:
>> >Lines 315-328:
>> >"ebXML Recommended Modeling Methodology
>> >
>> >"Business Process and Information Modeling is not mandatory. However, if
>> >implementers
>> >and users select to model Business Processes and Information, then they
>SHALL
>> >use the
>> >UN/CEFACT Modeling Methodology (UMM) that utilizes UML."
>> >
>> >Given its mandatory status, for the BPSS to diverge from the UMM
>> >Metamodel opens a hole in the body of ebXML specs.
>> >
>> >2. ebXML does not work in a vacuum.  It must be integrated
>> >with business collaboration processes beyond the 1.0 specs
>> >and also integrated with internal business apps.  Many people
>> >will want to do this in UML.  Many organizations that will want
>> >to use ebXML have already adopted UMM. Besides being
>> >mandatory, UMM is a actually a good methodology for
>> >developing business systems in which ebXML
>> >will be one of the collaboration technologies.
>> >
>> >3. For some people, UML is overkill.  For them, the BP group
>> >as a whole has agreed with the concept of a simpler
>> >Business Process Editor which can generate both
>> >UMM Metamodel compliant UML models (represented in
>> >XMI or RDF) as well as Spec Schema-compliant XML
>> >for use with CPAs at runtime.  We also had an agreement
>> >on a simpler subset of UMM that the BPE could edit and
>> >derive all of the artifacts for the whole Metamodel as well
>> >as the runtime XML.  However, this agreement was predicated
>> >on "one and only one metamodel".  If the BPSS and UMM
>> >are out of sync (which appears now to be the case), then
>> >the BPE developers are faced with the choice of which
>> >to support, Metamodel or BPSS, when the two of those
>> >should be semantically the same.
>> >
>> >I am not going to get into the differences between BPSS and
>> >UMM Metamodel in this message, only to highlight the
>> >issue and state my opinion which is that apparent differences
>> >should be considered to be guilty until proven innocent.
>> >
>> >(Some of the most important divergences are highlighted
>> >with line numbers in the related Transaction Integrity detail
>> >message.)
>> >
>> >Respectfully,
>> >Bob Haugen
>> >
>> >
>> >
>> >------------------------------------------------------------------
>> >To unsubscribe from this elist send a message with the single word
>> >"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>>
>> ------------------------------------------------------------------
>> To unsubscribe from this elist send a message with the single word
>> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>