Re: [ebxml-bp] Comments on latest draft of BPSS V2 spec' (part 1 of 2)

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

David,
Thanks for the detailed and thoughtful comments. My suggested 
resolutions inline. Those that should be discussed in the TC call are 
designated as TC DISCUSSION. I have a few more to finish and have broken 
the response into 2 parts. This is part 1 of 2. Thanks.

>Webber: Monica,
>Just capturing my thoughts and suggestions here as I read
>through the latest Feb 1 draft.
>
>Line 184 - references "six business patterns".  Since this is the
> first time this is mentioned - suggest we state them:
>
>six defined, business transaction patterns - Commercial Transaction
>Notification, Information Distribution, Request-Response, Request-Confirm,
>Query Response.
>Each pattern is considered and provided for in this specification.
>  
>
mm1: Agreed.

>Line 186 - add - Note to implementers; three broad assumptions are made with
>reference to developing BPSS-based solutions (notes from John on call
>today).
>
mm1: Already added and a proposed text sent to the list.

>Line 207 - I think we resolved this on todays call.  A note to the effect
>that we have a default set of profiles that are recommended for actions with
>business intent and without business intent for BSI and MSI.  Designers may choose to
>deviate from these as determined by their business requirements.  The specification
>however assumes these profiles represent the normal use patterns with BPSS.
>  
>
mm1: I think we have the patterns and have clarified semantics around 
them. They may be considered a profile. Then again, partners may 
establish their own criteria and then are responsible for the semantics 
(as we clearly specify for Data Exchange) which is considered a profile. 
We actually will expand on BSI-MSI in Sections 4 and 4.7 (list proposal 
made and agreed upon today). Suggest, then David, we add one mention in 
Section 4.5.2 after the patterns are listed (at end of section):

FROM: These patterns are the semantic guidance of the Business 
Transaction itself. A relationship exists between the 
format/requirements of the pattern and the semantics of each concrete 
Business Transaction pattern (that map to those in the UMM). Operational 
semantics and other criteria apply to these patterns. Where specified in 
a separate contract or agreement, any of these patterns MAY be 
intentional, and provide the basis of any obligation to yield accurate 
information.

TO: These patterns are the semantic guidance of the Business Transaction 
itself. A relationship exists between the format/requirements of the 
pattern and the semantics of each concrete Business Transaction pattern 
(that map to those in the UMM). Operational semantics and other criteria 
apply to these patterns. Where specified in a separate contract or 
agreement, any of these patterns MAY be intentional, and provide the 
basis of any obligation to yield accurate information.

[add] Agreements or other business requirements MAY guide or change the 
criteria surrounding any interaction between partners, which 
correspondingly influences the technologies used (such as that defined 
in a BSI or MSI). In essence, the guidance could result in a profile of 
the criteria selections of the defined pattern of the involved parties. 
Where the agreements actually change the baseline assumptions of these 
patterns, this could result in a partner-specific pattern and a 
subsequent profile. This is discussed in further detail in Section 
4.6.6.1. [end-add].

>Line 227 - punctuation seems clumsy!
>
>component, which is able to be, configured
>
mm1: Agreed. Also see we have some formatting to clean up here (italics 
and the like). Suggest this revision at that line in Section 4:

FROM: The ebXML Business Service Interface Software represents any ebXML 
compliant component, which is able to be, configured from an ebBP 
definition and a CPA.

TO: The ebXML Business Service Interface Software represents any ebXML 
compliant component. The BSI can [MAY??] be configured from an ebBP 
definition and a CPA.

>Line 269 - change - is the strictly identical for both parties
>to - is strictly identical.
>
mm1: Agreed (with spelling correction to your correction) in Section 4.2.

>Line 271 - change - This is what is referenced as "state alignment".
>to - This process of exchanging a signal to designate a change is the status
>of a business process is referred to as "state alignment" between two
>or more parties.
>
mm1: Let's try this for change in same section:

FROM: This is what is referenced as "state alignment".
TO: "The process of exchanging signals and state changes of a business 
transaction enables "state alignment" between the parties involved."

>Line 309 - Relationship to CC
>
>that abbrev' is too obtuse!  Suggest Spell out - thus -
>
mm1: I would suggest we spell out these other entities in each title of 
Section 4.4 (CC is only one). I also have to look at CPP/CPA references 
as I think it is the CPA only.

>Relationship to Business Transactions, Documents and CCTS / UBL.
>  
>
mm1: Suggest we say for Section 4.4.2 and provide a link reference to 
the v1.0 UBL:

FROM: ....XML based Business Document Specifications MAY be based on the 
ebXML Core Components specifications.
TO: .......XML based Business Document Specifications MAY be based on 
the ebXML Core Components specifications such as OASIS Universal 
Business Language (UBL).

>Line 315.  A payload may also be binary encrypted data where the content is
>an attachment such as a wordprocessing document that is digitally signed.
>From the BPSS perspective this is prefectly acceptable and the only
>requirement is that the MSI is able to recognise the type of content,
>verify it and then change the state management accordingly for the
>ebBP to show that the service/action has completed correctly.
>
TC DISCUSSION mm1: I suggest we discuss this one further with your 
suggested text to start the conversation. We talk about attachments 
later. We also don't dictate that the MSI can recognize and verify it. 
Like I said, it is a broader question than this text. We can discuss in 
Tuesday's call.

>Line 333 - Implementation note:- a WSDL-based interaction may not be
>capable of fully supporting complete business interchange requirements
>in the same way as ebMS.  Care should be taken to ensure that adequate
>agreement with partners exists so that they understand the business
>obligation impacts. With the current implementations of WSDL-based
>exchanges they are not always completely interchangeable with ebMS,
>but only a subset.
>
mm1: I think we should consider this more carefully, recognizing the 
assumption of risk lies with the parties involved (given the technology 
they choose). That is the important point to make. Suggest we add to 
Section 4.4.4:

Implementation note: The possible capabilities of the underlying infrastructure and services chosen may impact the capability to support business requirements defined by the involved parties. For example, specific constraints may apply to WSDL-based exchanges that may not exist for those implementations using ebMS.

>Line 333 - Add two sections
>
>4.4.5 Resolving Logical Document References to Physical Transactions.
>
>BPSS refers to logical documents as the means to convey business information
>between participants in an ebBP.  To resolve between logical documents and
>actual documents various mechanisms are available.  If there is a one-to-one
>correlation then a simple schema association may suffice and this can be
>done by referencing to a URL or URN that locates the schema.  However
>if multiple transaction formats may be selected depending on partner role
>and context then the OASIS CAM mechanism and templates is designed
>to work with BPSS variables and XPath expressions to enable dynamic
>selection of physical formats that match the logical ebBP service and
>action requirements.  Figure 4 below illustrates these concepts.
>
mm1: David, we do not specify how this is done. More appropriately, I 
would suggest an addition sentence or two in Section 4.5.3 where we talk 
about business document flows.

FROM: The acctual business document definition MAY be achieved using the 
ebXML core component specifications, or by some methodology external to 
ebXML but resulting in schema definitions (XSD or DTD) of which an ebXML 
/Business Process definition/ can reference.

TO: The actual business document definition MAY be achieved using the 
ebXML core component specifications, or by some methodology external to 
ebXML such as OASIS Content Assembly Mechanism (CAM). The specific 
context, format or other business requirements may require different 
approaches to provide the schema definitions (XSD or DTD) used for 
message exchange and of which an ebXML /Business Process definition/ can 
logically reference.

There is a later section where we talk about variables more deeply in 
Section 4.6.8.1. Suggest:

FROM: XPath and XSLT (Extensible Stylesheet Language Transformation) are 
recommended, particularly when multiple condition expressions and 
variables are used.

TO: XPath and XSLT (Extensible Stylesheet Language Transformation) are 
recommended, particularly when multiple condition expressions and 
variables are used.
Other technologies that also may also support the use of condition 
expressions and variables include OASIS CAM.

>4.4.6 Using BPSS in combination with ebXML Registry.
>
>While use of an ebXML Registry is not mandated for BPSS as
>all parts of ebXML are designed to work independently as needed
>there are significant advantages that can be gained when BPSS is
>used in combination with registry.
>
>The BPSS and CPA both contain UUID reference attributes.  These
>allow referencing to specific instances - either ebBP or CPPA - that
>actually reside in an ebXML Registry.  Also - BPSS models and ebBP
>instances can be stored in the registry and classified as part of a
>business process catalogue.  An industry group or an enterprise
>can then maintain and share that catalogue with partners and
>participants as needed.  The registry can also be responsible for
>versioning and managing the actual ebBP and BPSS model instances
>as well as providing a repository for runtime instances for partners
>derived from design time templates (see Figure 10 below in section 4.6.6.8).
>
mm1: This is an important suggestion David. Suggest a slightly shorter 
addition (given the scope of the overall section) for Section 4.4:

TO (from your suggestion above to add a new section):

Although independent, the ebXML components are designed to work together in a loosely coupled fashion. At a minimum, the 
ebXML Registry/Repository could allow the discovery and use of ebXML BPSS instances. If artifacts are given a classification, the instances and the profiles of the BT patterns could be part of a business process catalogue. They may be available to an industry group, enterprise or entity. The ebXML Registry/Repository provides the capability to version and manage such artifacts (See the figure in Section 4.6.6.8).

>Line 354 /355 - current order works for me - why are we thinking otherwise?
>  
>
mm1: I would ask you and Sally collaborate. This was a suggestion from 
Sally. Thanks, David.

>Line 364 - multiparty... - involve two or more roles and more than two
>participants.
>
TC DISCUSSION mm1: I'd ask we have TC discussion on this one, I pondered 
how to properly state this with a similar question raised by Sacha 
Schlegel. We actually have the initiator and the responder that can 
assume multiple roles.

>Line 371 to 377 are too obtuse - can we give a concrete example?
>  
>
mm1: Boy, on an additional read, I agree. Suggest for Section 4.5.1. 
Please let me know if you think an example is now needed (and if so, 
propose one).

FROM: The ability of a Binary (Business) Collaboration to have 
activities that in effect are executing other Binary (Business) 
Collaborations is the key to recursive compositions of Binary (Business) 
Collaboration, and to the re-use of Binary (Business) Collaborations. An 
activity, whether it is a Business Transaction Activity or a 
Collaboration Activity represents the usage of a definition within a 
Binary (Business) Collaboration Specification. For instance, a Business 
Transaction is defined once and for all, but could appear several times 
– as a Business Transaction Activity -, sometimes even with opposite 
roles, within the same Binary (Business) Collaboration.

TO: The ability of a Binary (Business) Collaboration to have activities 
that in effect are executing others is the key to recursive compositions 
and re-use of Binary (Business) Collaborations. For example, an 
activity, whether it is a Business Transaction Activity or a 
Collaboration Activity MAY represent the usage of a definition within a 
Binary (Business) Collaboration Specification. For instance, a Business 
Transaction is defined once. However, the BT could appear many times as 
different Business Transaction Activities, where the roles change within 
the same Binary (Business) Collaboration such as for an Offer and 
Counter Offer. In that case, either partner may assume the initiating role.

>Line 379 - formatting.
>
mm1: Corrected above.

>Line 408 - typo - fails from a protocol perspective
>
mm1: In Section 4.5.2:

FROM: A Business Transaction MUST succeed or fail from both a technical 
and business perspective.
TO: A Business Transaction MUST succeed or fail from both a technical 
and business protocol perspective.

>Line 409 - typo - prior to (a)
>Line 410 - typo - In the case of (b)
>  
>
mm1: Also in that section then:
(a)
FROM: In addition, if it fails from protocol perspective, each party 
MUST synchronize their state to the state prior...
TO: In addition, if it fails from protocol perspective, each party MUST 
synchronize their state to the state prior to...
(b)
FROM: In case of a business failure, the state has already been 
“synchronized” ....
TO: In the case of a business failure, the state has already been 
“synchronized”....

>Line 413 - change - and based on information not available to the BPSS
>to - and based on information and rules that are not directly part of an
>ebBP instance but reside outside or are referenced by the ebBP instance (such as a link
>from the logical BPSS document to a physical transaction format and rules
>template).
>
mm1: I think part of this is answered earlier in this email but here is 
an addition (also in Section 4.5.2). We already touch on the 
logical-physical elsewhere.

FROM: A Business failure is any failure that is identified by an 
application during the processing of the business document(s) and based 
on information not available to the BPSS.
TO: A Business failure is any failure that is identified by an 
application or service during the processing of the business document(s) 
and based on information not available in or part of the ebXML BPSS 
instance.

>Line 421 - change to - Notification (or Notification of Failure (NoF))
>  
>
mm1: Agreed (continues in Section 4.5.2).
FROM: Notification (of Failure)
TO: Notification (or Notification of Failure [NoF])

>Line 433 - responding parties performing roles.
>
TC DISCUSSION mm1: Agreed in Section 4.5.3. I'd like to link this 
however, to the earlier TC discussion item to ensure we are consistent.
FROM: A business transaction is realized as Business Document flows 
between the requesting and responding roles.
TO: A business transaction is realized as Business Document flows 
between the requesting and responding parties performing roles.

Line 435 - (but not Notification of Failure).   - [watch spelling on failure
too!]

---------
mm1: Same section.
FROM: (Not Notification of Failiure)
TO: (Not Notification of Failure)

 Line 437 - typo - acctl

-----------
mm1: Caught in an earlier comment.

Line 439.  Add sentences.  -  The basic schema definitions can be augmented
with business rule templates.  The purpose of these templates is to work
in cooperation with the ebBP variables mechanism and to allow role based
context to be dynamically applied to document transaction processing
at the MSI layer.  An example of this is using the OASIS CAM templates.

--------
TC DISCUSSION mm1: David, I added text in an earlier comment in this email. I think your comments straddle the scope of v2.0 and v3.0 (not yet addressed).

Line 486.  Add sentences.  - The BPSS now contains a variable declaration
mechanism that can be used in combination with role to determine the context
for a particular participant in a collaboration.  This context can then be
used by
transaction assembly and validation services as part of the BSI and MSI to
control the handling of business transactions accordingly.

=========
TC DISCUSSION
mm1:  For Section 4.6.1, suggest TC discussion re: this as we have not scoped validation services (underlying the process).

Line 499. Change - If one or more party wishes...

=================
mm1: In Section 4.6.1 as well:
FROM: If one of the party wishes to participate on the basis of one or more web service definitions the....
TO: If one or more parties wish to participate on the basis of one or more web service definitions the....

Line 521 - this involves steps 1 through 3 above.

===========
mm1: Agreed in Section 4.6.2:
FROM:  This involves only numbers 1 through 3 above.
TO:   This involves steps 1-3 above.

Line 524 - spelling - example.

=============
mm1: Same section:

FROM: ....diagrams, for exanmple.
TO: ....diagrams, for example.

Line 565 - typo - a an

========
mm1: Section 4.6.3.1:
FROM: An include element provides a an ebBP definition...
TO: An include element provides an ebBP definition...

Line 574 - XInclude / XPointer - I did not realize we are using this.  I
would
strongly prefer to make this non-normative.  XPointer and XInclude is a
whole another implementation burden.  Also we should explicitly state that
XIncluded content may *NOT* contain further XIncludes (eg no nested
includes).
I would prefer that we have a simple <bpss:include location="URL"/> as a
simple directive, as an alternate mechanism.

========
TC DISCUSSION mm1: This mechanism was developed in the October 2004 Editors' F2F and briefed to the team.
Suggest we further discuss. Dale or JJ, please weigh in here.

Line 605 then becomes instead of "replaces" change to "is an alternate for".
Retaining the <bpss:include /> mechanism will also allow use of http-binding
references via a LID(value)  to content in an ebXML Registry.
I think making XPointer support required will draw us very heavy flak
from the XML-dev crowd - and almost certainly delay our specification
due to comments in public review phase - let's make it discretionary
and optional at this stage.

==========
TC DISCUSSION mm1: Section 4.6.3.3. Relates to your comment above.