Re: BPSS Strategic issue: one and only one metamodel

[Jim Clark <jdc-icot@lcc.net>]

Karsten Riemer wrote:

> Jim,
> Please be specific.

I would be happy to.

>
> 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.

I did not agree to leave it as is. I raised several strong objections to various
issues and was told that this was the decision made and it would not change. It
became apparent that my issues would not be redressed unless I made them part of
the formal review. I find it interesting that until the public review occured, not
a single issue in the issue list had my name on it though I have raised numerous.

I do desperately what this to succeed.

>
>
> 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.

Absolutely

>
>
> 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.
>

Again, agreement - I think Jamie can help us here.

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

No - These are rightly part of the process/activity that conducts the business
transaction.
Any parameter associated with the document flow should be descriptive of the
structure and state of the document being exchanged.
There are legitamate parameters for the document flow.

>
> 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

Responder must send a signed-tamper proof ack/doc because the requestor will
time-stamp it, tampered-proof it and save it. It would be wise for the responder
to doe like wise.

>
>      isNonRepudiationOfReceipt required means must receive signed rcptAck

and tamper proof

>
>      isIntelligibleCheckRequired means rcptAck implies validation

Forces 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

see above

>
>      isIntelligibleCheckRequired means rcptAck implies validation

Not appicable to response.

>
>
> Is this the correct distribution of parameters?

Other than they do not belong on the flows

>
>
> 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.

Yes, this is correct. This is reflected by the timeToPerform parament in the
BusinessTransactionActivity which constrains the duraction of the BT overall. The
timeToPerform on the BusinessAction is constrained  by this value and reflects the
time in which the action itself has to perform it's activity. On the requesting
side this value may or should be the same. On the responding side it may not be.

Best regards and thanks for the effort.

Jim Clark

>
>
> -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
> >

begin:vcard 
n:Clark;James
tel;cell:936.524.4424
tel;work:936.264.3366
x-mozilla-html:FALSE
org:I.C.O.T.
adr:;;10987 Quinlan N Lake;Conroe;TX;77303;
version:2.1
email;internet:jdc-icot@lcc.net
title:Principal Consultant
fn:James Clark
end:vcard