Re: [ebxml-bp] Groups - ebbp-f2f-mtgminutes-forteam-042804.txt uploaded

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>The document ebbp-f2f-mtgminutes-forteam-042804.txt has been submitted by Monica Martin (monica.martin@sun.com) to the OASIS ebXML Business Process TC document repository.
>
>Document Description:
>Meeting minutes for ebBP informal TC at OASIS symposium 28 April 2004.
>  
>
mm1: I recognize that some interested observers and guests may not have 
access to the TC pages. Therefore, I have attached herein the meeting 
notes for the informal TC meeting at the OASIS symposium. Forgive any 
duplication for our other members. Thanks.
Informal ebBP TC Meeting
28 April 2004

Sacha Schlegel-O [1]
Sally St. Amand-V [2]
JJ Dubray-V (phone)
Zinovy Barch-V (phone)
David Webber-V (phone)
Neelekantan Kartha-V 
George Lee, ITT-G [3]
Dale Moberg-V
Bob Haugen-G
Johannes Chiang-National Cheng-Chi University-G
Anders Tell-O
Kenji Nagahashi-V
Monica J. Martin-V

[1] Observer
[2] Voting member
[3] Guest

Agenda summaries posted: http://www.oasis-open.org/archives/ebxml-bp/200404/msg00100.html
Informal TC meetings summary 2 May 2004: Not yet archived to Kavi.
Draft schema posted 28 April 2004: http://www.oasis-open.org/archives/ebxml-bp/200404/msg00130.html
Notice on impending votes (12, 43-66, 44-57) on 30 April 2004:
http://www.oasis-open.org/archives/ebxml-bp/200404/msg00136.html
Meeting note summary 2 May 2004: Not yet archived to Kavi.

Martin: Concentrate on work items for v2.0 and schema, then technical specification.
Moberg: Implementations required - Adobe, RosettaNet, Sterling, Cyclone, and others under
discussion and being considered. Possible uses: Monitoring, set groundwork for CPPA generation
If we can concentrate this, we can ensure loose coupling and alignment with CPPA
and show commercial relevance.

Martin: Summary of changes discussed:
a. Role bindings
b. Business transaction patterns
c. Signal specificity
d. Expressions and constraints conversion to entities
e. WSDL support

Moberg: Need to identity roles in referred to and referring context for a collaboration activity.
Key is to make explicit definitions on roles to allow for associations between
roles (and their changes in a collaboration). Accommodate differences that could be applicable between binary and multi-party
collaboration. Talk about use of UML activity diagrams.
Talk about fork-join constructs and business state links (pseudo states are given
a graphical structure that relates it to prior states). Explicit links
rather than implicit in the grouping in the BPSS instance. Makes the transition
model explicit. Resolve use of Transition and onInitiation flag vs. deprecation of transition.
Need to be able to handle loops, for example to support CPA negotiation.
Haugen: Are each BPSS instance executed separately or will an engine interpret these and
use them?
Moberg:
a. Monitoring - state alignment, paths through a graph to any different completion states.
b . CPA support
Checking the session for the allowable paths.
Haugen: How does this relate to where RosettaNet had separate programs per PIP or a generic engine that handles any PIP 
provided to it.
Moberg: Lean towards engine. 
Kartha: Agrees. Could also translate BPSS into an interim description language.
What is timeline for the schema?
Martin: Goal is to have a draft schema by the end of May 2004.
Webber: Does using translation to workflow capabilities for BPSS?
MPC involves linking and switching that is in BCM.
Moberg: Fork-join 1-1, 1-m and m-1. Need to have constructs for link notation.

Issue 11-Packaging
(Relates to 13, 19, 28, 47, 54, 69)
Fork-join
Moberg: Join has a documentation element and add a BusinessStateLink 1..n.
Fork and join have unbounded links. The Transition has 1-1 link.
This does not rely on order of sequence.
Business state link has attributes - provide business state name and IDREFs.
Semantics-AND/XOR do not change.
Dubray: That is good. A collaboration is not executable and the notion of a fork
has to have different meaning that what you have in a process execution language.
Business states do not change. The apparatus of the pseudo states do change.
Kartha: It is implicit what is the source and what is the destination, correct?
Should we identify source and target?
Moberg: This may not be the most efficient path with From-To or we could entertain 
source-target.
Schegel: Are fork, join and choice sufficient for what you want to express in BPSS?
Moberg: We also have success-failure, links and decision as well.
St. Amand: Transitions have high utility for business people and analysts. Looping is familiar.
Moberg: Have not evaluated document inclusion clearly. Do we jump from one package
to another?
Dubray: You have to model to have reusable elements. This requires identification
and typing, which is not well supported in the metamodel. 
Moberg: Use packages as units. Document for the implementor. 
Martin: This relates to well-formedness rules or constraints.
Moberg: Well-formedness rules required.
Example: A rule could be When a BTA refers to a BT, this requires use of an IDREF that belongs
to a BT.
Currently, there is no mechanism to have a binary collaboration point to a MPC.
Need to allow transition from BC to MPC (break MPC into BC).
GM wants reporting for dashboard of activities.
St. Amand: Need to understand global processes and how one process affects others.
Moberg: Concentrate on business state alignment.
Martin: Isn't the difference of BC and MPC only different with the number of roles?
Dubray: Extend the notion of BC by the roles participating.
What you lose is the ability to form clearer agreements. What do the parties
do? 
Moberg: Separate into three CPPs for Customer-Distributor, Distributor-Logistics, and
Distributor-Credit Check.
How do we express constraints and time limitations?
Dubray: Current limitation of v2.0, it assumes there is no shared context.
Uncertain if we can support MPC without shared context.
We have to create a message to synchronize parties as to the state changes that may occur
between BC and MPC that occur within a larger collaboration. Messages may lack
business meaning; therefore, this points to need for shared context.
Specific messages could provide shared context if desired which is constraining.
Postpone to v3.0.
Moberg: In Collaboration Activity, can I go to a MPC and a BC, not just BC?
Allow for a choice for transition for a MPC and BC.

RECOMMENDATION:
v2.0: Add BusinessStateLink to accommodate explicit transitions in order to alleviate
reliance on ordering in BPSS instance. Provide a description in the technical specification
that the collaboration is not executable and the fork has a different meaning at the
business level.  Business states do not change; the apparatus of the pseudo states do.
v3.0: Investigate use of shared context to further accommodate MPC, recognizing that 
sending messages alone for state alignment may be constraining and insufficient.
Accommodate transitioning to MPC and BC in a CA (need to handle various combinations of 
MPC and BC within a BC and the segmentation/visibility required).

Note: We had a good collaborative session with WS-CAF. See reference at the beginning of the TC meeting minutes.

Work Item 47 State of binary collaborations
(Relates to 11, 13, 19, 28, 54, 69)
Moberg: Which binary collaborations effect a start?
Martin: Isn't in the order they appear in the BPSS instance?
Moberg: How do you process the binary collaborations related to role?
Need to know start state of the graph of the monitoring tool and to build the CPP.
Dubray: Don't see the ambiguity of the start of a collaboration.
The start is a transition of pseudo state to a CA or a BTA - this is the first
BTA that is expected to happen.
Moberg: Take this case, CA with 5 BC. Are these distinct process starts?
Dubray: Ambiguous if fork after a start. Ambiguity is desired there. You accept multiple starts.
Moberg: Which one of the 5 binary collaborations are to be supported or monitored?
Dubray: The parent collaboration choreographs the 5 collaborations.
Can logically transfer start - this is the first BC activity that has a start
element that has this BTA which is the one that occurs.
Agree, if you have 5 BC with no CA? The same BTA starts 5 BC; there is an ambiguity
which one you start.
Moberg: Have to indicate role to play and activities with which to engage.
Do we need to specify that explicitly?
To me this is a correlation. It can happen on different grounds - message type
1=1 to collaboration. Otherwise, you require an envelope mechanism.
Dubray: Define a logical business document that relates to a physical business content.
Moberg: Tool needs to understand pack that is applicable.
Dubray: The tool would use both BPSS and CPPA (for correlation).
Martin: Is this an implementation detail?
G. Lee: There is no fundamental difference between BC and MPC except for state and roles.

RECOMMENDATION:
v2.0: Role binding and Performs need to be supported. Need to quantify
that a CA can transition to MPC or BC. 
v2.0: Place note that when you have multiple BC that is not an InnerCollaboration,
tools will be required to choose or select those that need to be followed
(and may allow use of references in other specifications such as CPPA).
Leave it to CPPA how many CPP would be required in this instance. Evaluate iteratively.
v3.0: Understand business requirements for shared context.

Work Item 73 - Decision state content model
Moberg: Decision will look like a condition expression.
a. BusinessStateLink to and from, optional BusinessStateLink for choice (if-else)
b. Condition expression
c. Documentation
Transcribes from UML for FROM state to multiple possible TO states.

RECOMMENDATION:
v2.0: Provide content model for decision state.  See Moberg draft schema (reference at the start of these meeting notes).
Accommodate a FROM state to multiple TO states.

Work Item 72 onInitiation
Moberg: Transition was deprecated. If so, how can we accommodate nesting.
onInitiation was to be used for nesting construct. Why is this put on a transition?
Added BusinessStateLink to the Transition in addition to the existing Condition Expression and Documentation.
Dubray: Use an AND or OR fork if you do not know the sequence of a set of activities. If the sequence is important, use onInitiation.
Moberg: Have a BTA followed by a transition. We follow the states in the order shown.
The onInitiation affects how we see and execute against these activities.
Awkward to be forwad looking at the Transition, with onInitiation, to understand
how to execute the BTAs.
Dubray: Allow inner BTA to occur. 
Moberg: The BTA references a unit.
Dubray: Inner BTA is only valid after the parent BTA is executed.
Without onInitiation, there are no semantics on sequence that are to be achieved.
Tell: Possible to do the same thing with collaborations.
Moberg: Yes possible. Transition to CA.
Ways to handle states:
a. Listing of states
b. References (via inclusion)
c. Transition
Suggestion is to subordinate BTAs to the Transition.
Dubray: As long as we support Req-Resp for BTA, this is acceptable.
Nesting need to be blocked to support processing simplicity.
Same solution applies to Fork.

RECOMMENDATION: 
v2.0: Transition is essential for looping.
Retain. Transition is still a pseudo state.
Syntactically change the construct where you can have a Start-Transition (with
parent-child BTA) [from] to Success-Failure [to]. This allows the blocking
of execution for processing simplicity.
v2.0: Same applies to content model for Fork.
v2.0: onInitiation is retained as defined.
Indicate more explicitly its use in the technical specification.

Work Item 23 Composition - Relevance of Attachments and Business Documents
(Relates to 25, 32)
Moberg: This could be handled by the CPPA.
Dubray: Content management systems have metadata associated to a document.
Do we add metadata to attachments or use that of the business document?
Moberg: Those seen in Dublin Core for example.
Martin: You may see the attachment is not parsing friendly.
Dubray: Expect that the attachment is not parsing proper.
Moberg: Document metadata is appropriate for the language that checks the conditions.
Martin: Do we say then that the ConditionExpression doesn't interrogate 
the attachments. 
Tell: What about the completeness states? Check for the MIME type and could eventually interrogate the content (where applicable).
Moberg: Proposed to hold all the attributes like the DocumentEnvelope.
Dubray: We should not be interrogating or parsing other blobs (attachments).
Providing metadata to allow the BSI to recognize the attachment but not interrogate into
it. Requiring the BSI to validate the attachment we sent would be dangerous.
Tell: Could add cardinality to specify number required; multiplicity; required or not.
How can you recognize SBDH?
Moberg: Does this go past the boundaries of BPSS?
Martin: Agree.
Moberg: Use Documentation element for metadata.
Dubray: Differentiate type and instance metadata.
Reference the Document Type. BPSS would not be responsible for instance level
metadata.

RECOMMENDATION:
v2.0: Attachment should not affect the processing in the BSI. However the BSI should be
able to recognize the metadata associated with the Attachments although it doesn't 
interrogate into it.  The metadata boundary is type not instance.
v2.0: Consider other attributes once further clarification provided by Tell on difference between an attachment and
an appendix (which may relate to his question on validation):
Cardinality, multiplicity, and required/optional.
May be able to use Documentation element.
v2.0: ConditionExpression could support assistance of recognition of the documents
including attachments. Add Attribute to call out business features (leaving processing
to CPPA).

Issue 74 isAuthorizationRequired
Dubray: The BSI has to check that the partner is allowed to perform this transaction.
Delegate to a directory service to check. Serves as a hint for the BSI.
Want to surface any exceptions back to the Sender on which to act.
Authorization exception required.

RECOMMENDATION:
v2.0: Need to add exception to support authorization exception.
v2.0: Retain isAuthorizationRequired attribute.

Work Item 43 Name and NameID
(Relates to 66)
Nagahashi update 26 April 2004: 
http://www.oasis-open.org/archives/ebxml-bp/200404/msg00125.html

Moberg: Don't believe names should be unique.
Implementation are warned that if documents are combined, the NameID don't collide.

RECOMMENDATION:
v2.0: Set up a vote for Solution 2 amended and allow for Other if any other option
is preferred. Notice given 4/30. Open 5/7. Close 5/14.

Open new v3.0 work item:
Moberg: UUID is the value of Service. What does Service refer to? A process specification refers
to many services, per Roberts. UUID on process specification is the identifier for a Service.
Is the BPSS more than one service? Can we shift that to the name on a Binary Collaboration?
Do we allow it to be a choice? That makes alignment with CPPA and ebMS more difficult. It goes into the Message Header.
Retain for v3.0: ebMS, CPPA and BPSS alignment. No change for v2.0.

Work Item 53 Time to Perform / Inner-Outer Collaboration
Martin: Establish potential attributes on TTP element for conditionality. This may also apply to other attributes that
should be elements in the future.

Possible attributes or conditions:
1. Duration
2. Type - Provide range of enumeration values.
a. Design
b. Configuration
c. Runtime
3. Default 
4. Default type
5. Build conditionality into the Type for when it can be changed.

St. Amand: There has to be a dependency acknowledged.
Martin: TTP must be > in Outer for Inner collaboration.
Moberg: Need to establish upper boundaries.
Kartha: Can you express in schema?
Tell: What about subtyping of Duration? Static or other way to specify.
Allow you to take out a value from another location.
Could use an abstract superclass that includes TTP, and develop specific subtypes that allow further specification.

See Tell proposal subsequent to F2F: 
http://www.oasis-open.org/archives/ebxml-bp/200404/msg00131.html

RECOMMENDATION: 
v2.0: Establish finite set of attributes, constraints and conditionality for TTP. Lay groundwork for other attribute-element
changes for v3.0.
v3.0: Re-evaluate all relevant attributes for such a transition.

Work Item 26 Out of band communications
(Relates to 45)
Martin: Need to handle something that is out of band and get state alignment in the BSI. Do we set to the desired state or simulate the manual occurrence?
Moberg: Document language occurs and establish a new entry point.
Haugen: Do we get state alignment? What about evidence?
Moberg: Recommend treat as a separate process. What about the impacts to CPPA and ebMS?
Each of these could be true: Technical failure with compensating action, special process definition, or exceptional
condition. Problem changes if you start (request) or respond manually. Latter recognizes that  a condition has to be accommodated.

=============================
Previous discussion on this in February F2F
Work Item 45 - Transactions performed on other channels
Martin: This is a BT use case. We need to: 1) Allow the send of the response even though the request was out of band,
2) Any party can enact a BTA, or 3) Allow request to be sent after response.
Moberg: This is problematic for ebMS that expects a RefToMessageID.
Roberts: This is customer driven in BT.
Moberg: You could have a delegated submission.
Roberts: No. A notification is required to align state when a business message occurs out of band. How can we specify
that a BTA could be initiated by either party.
Martin: Can it be a signal notifying of the event?
Roberts: This has to be the business message and business document.
Nagahashi: RosettaNet is having the same problem. This relates to shared state and the objects.
Roberts: If one object gets out of step, the same state problem occurs. Object state can be changed in many ways.
The default on a transaction is it cannot be reversed. Need a flag.
Martin: Won't an acceptance be required?
Roberts: That is an interesting concept. Application systems have to be more aware of gateway events.
=============================

RECOMMENDATION (Integrated with discussion from F2F Feb 2004 on WI-45):
v2.0: This is not completely understood particularly with the impact to ebMS-CPPA and for ebBP state alignment.
Clarify if we can provide a flag in v2.0 (at a minimum) to acknowledge an out of band process could occur).
Determine if acceptance is required. Default behavior is as specified today.
v2.0/3.0: Need to gather more use cases. Query BT on their original use case. Understand the side effects.
Need more inputs from Roberts, Tell and Yunker.
v3.0: Resolve NOF touchpoint.

Work Item 36 Notification of Failure
Martin: Need more requirements on how NOF is used.
Nagahashi: General failure notification applies in RN. This typically is used after a 
ReceiptAcknowledgement. Implies, for example, something is wrong with order.
Tell: Need to provide notification that I expected a message and didn't receive.
Need to ask for information rather than stating you didn't receive.
This supports legal literature.
Haugen: Negative ReceiptAcknowledgement could be used.

=============================
Reference: v1.1, Section 5.14.2.3
isNonRepudiationOfReceiptRequired.
Both partners agree to mutually verify receipt of a requesting business document and that the receipt must be non-
repudiable. A requesting partner must initiate a notification of failure business transaction business (possibly revoking a
contractual offer) if a responding partner has not properly delivered signed their receipt. For a further discussion of
nonrepudiation of receipt, see also the ebXML E-Commerce and Simple Negotiation Patterns.
=============================

RECOMMENDATION:
v2.0: Set up special session to further breach subject of NOF.
v2.0: Get more information from usage by RosettaNet that originally defined NOF.

Work Item 44-57 White space
Martin: Should we use NormalizedString and facets in XML schema?

RECOMMENDATION:
v2.0: Discussed with ebBP and CPPA teams. Consensus was to leave the white space issue to implementation and trigger
a fault/exception. Don't use normalized string nor the XML instance suggestion from Webber.
v2.0: Put hints in technical specification.

=======================================
Economic commitments and legal references for eCommerce
Focused on relevance to ebBP v2.0.

UBAC Overview, Anders Tell
Merge legal, business and technical perspectives.
Provide requirements to other specification efforts for capability to support
ICC goals and expectations.
Look at UNCITRAL international eCommerce provisions.
Requirements for dispatch (exited your system) and reach (another system).
Involves release of control (push, access, and pull).
For example, push reach: Addressee gets the information pushed to them and they have control in 
their information system.
Need to separate different legal relevance of ReceiptAcknowledgement and AcceptanceAcknowledgement.
Former is part of the business transaction and the latter may apply to the contract formation
process.
Need to talk about accepting a response.
Haugen: Is the AcceptanceAck part of the contract formation process and the 
Response is not?
Tell: Have not decided - many ways exist to form a contract.
Haugen: Have to address these contradictions:
a. AA=+ Response=- (or change offer)
b. AA and Response=+ ReceiptAck=Negative ReceiptAck

RECOMMENDATION:
Finish and distribute summary notes on UBAC as well as slides.
Set up a session to talk about dispatch-reach.
Work with ebMS to ensure alignment.

Note: Look specifically at slides 4, 5 and 29 - a shortened set will be provided and uploaded.
Reference:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/6584/UBAC_overview_allslides_20040312.pdf

==================================
UNITED NATIONS COMMISSION ON INTERNATIONAL TRADE LAW (UNCITRAL)
UNCITRAL Model Law on Electronic Commerce with Guide to Enactment, 1996, with additional article 5 bis as adopted in 1998
<http://www.uncitral.org/english/texts/electcom/ml-ecomm.htm>

United Nations Convention on Contracts for the International Sale of Goods (Vienna 1980) ("CISG")
<http://www.uncitral.org/english/texts/sales/CISG.htm>

A/CN.9/WG.IV/WP.90 - Possible future work on electronic commerce - Transfer of rights in tangible goods and other rights
<http://www.uncitral.org/english/workinggroups/wg_ec/wp-90e.pdf> 

TRADE FACILTATION RECOMMENDATIONS INCLUDING ICC
http://www.unece.org/cefact/trafix/bdy_recs.htm
==================================

ACTION:
4/28 TEAM: Establish definition of the role of UML activity diagrams in BPSS.
4/28 MARTIN: Talk to Anders about appendix for attachments, cc: Johannes
Chiang
4/28 MARTIN: Open Kavi vote for WI 43-66 to propose Solution 2 amended for vote and
approval. Notice 4/30. Open vote 5/7/2004. Close 5/14/2004.
4/28 MARTIN: Open issue related to Service definition for ebMS-CPPA-ebBP alignment for v3.0.
Ensure requirements understood by UBAC as well for v3.0.
4/28 MARTIN: Talk to Anders about what attributes required for TTP and other conditional
elements (WI 55, 53). Provide the schema to Tell. He will provide an abstract
class and diagram to describe.
4/28 NAGAHASHI (36): Get high-technology requirements for NOF (scope and usage).
4/28 MARTIN: Set up special ebBP call to talk about what attributes should be changed
to elements to allow for conditionality.
4/28: MARTIN: Set up special ebBP to talk about Business Signals, NOF and exceptions.
4/28: MARTIN: Upload reference to UNCITRAL and ICC guidelines to reference
and understand. Relevant to business semantics in ebBP. DONE WITH MEETING NOTES 2 MAY 2004.
4/28: MARTIN: Upload the UBAC overview document to ebBP. DONE 2 MAY 2004.
4/28: MARTIN: Open action item for Cyclone Commerce developers to provide inputs
on what is missing from ebBP in order to support monitoring usage of BPSS (Moberg).
4/28: MARTIN: Set up final vote for WSDL support WI 12. Notice 4/30. Open vote
5/7. Close vote 5/14.
4/28: MARTIN: Set up final vote for White Space WI 44-57.  Notice 4/30. Open vote
5/7. Close vote 5/14.
4/28: MARTIN: Send comparison to George Lee. DONE 2 MAY 2004.
4/28: MARTIN: Send ebBP meeting minutes to ebXML IIC (Kass). DONE 2 MAY 2004.
4/28: MARTIN: Coordinate with Tell to provide summary notes to ebBP team on UBAC.

NEW WORK ITEM:
4/28: Differentiate between substantive and supporting other unstructured
documents. Reference appendix that is another dialog or process instance that 
would be part of or outside of the parent proces.
4/28: What is a service in BPSS? In v3.0, open new item on choice of level
of service defined in ebBP. Talk to ebSOA.