ebBP 2/4/2005: Webber Questions (part 2 of 2)

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

Here are the second set of questions from David. Most have been resolved and others aired in our meeting 8 February 2005.

Line 622.  For references to registry instances it is suggested that the
use of Logical IDs (LIDs) be used as an alternate to UUID values.
LID values in Registry are referenced to the External ID value in the
RIM (registry information model).

============
mm1: Assuming you are addressing Section 4.6.4 Versioning, David: I am uncertain we should get to this level of detail. We use a logical ID, via the nameID for referencing. We also don't require use of a "UUID" (128 byte GUID). This is discussed in Section 4.11.1. I would presume this could be a part of a good technical note David on how BP artifacts are available for discovery, storage and used with Registry/Repository support, addressed outside of the technical specification. Please advise if you believe more detail is required.

Therefore, I would suggest a brief reference in Section 4.6.4:

TO: 
[add to the end of the section]
The use of NameID for referencing is detailed later in Section 4.11.1.

Line 678 - typo - remove "is".

=======
Section 4.6.6.1

FROM: This element is abstract, it is does not appear in ebXML BPSS instances.
TO: This element is abstract, it does not appear in ebXML BPSS instances.

Line 1059 - actually I think the arrows are OK!  The flow is up from
the bottom into the CPA and out to originating CPPs.  Another way
of looking at this is to drop the CPPs pictures entirely - and just
have two boxes "Partner A" and "Partner B".  This is more inline
with the modelling process - where we define the BPSS and
then roles - and assign partners to those.  We do *not* go out
and canvas for CPPs who can perform those...instead
the CPA comes "pre-baked" and people simply fill in their
demographic information.

========
mm1: If you believe the arrows are correct (as they were), please discuss with 
Sacha, as he requested they be corrected. In reviewing these, I think the change is correct.
Dale and Sacha, please advise. 

Line 1061/1062 - change this to "create a CPA that references the WSDL
file(s)
that reference the service/action from the ebBP" (see section 4.7 for more
details).

=============
mm1: In Section 4.6.6.8, suggest below. Remember, the CPA may not use ebBP, particularly with the changes in the v2.1 errata CPA spec.

FROM: If a business partner is capable of web services only, all it needs to do is to create a simple Collaboration Protocol Profile which references the WSDL files
which contains the appropriate operations. 
TO: If a business partner is capable of web services only, it can create a simple Collaboration Protocol Profile which (1) references the WSDL files that contains the appropriate concrete operations and (2) may also include the service and actions that map to the ebXML BPSS process definition.

 [again CPP is not OK - because a MSI will not be able to process that as its
 only  one leg - and you need both legs (CPA).]  The role of the CPP is to
allow people to search and find potential partners - we're not doing that
here.
Again - see section 4.7

============
mm1: Assuming Section 4.6.7.1, see below. In addition, I think we should check each reference to CPP or CPA and ensure we are correct in use, and also correct name of the specification: Collaboration-Protocol Profile and Agreement 

FROM: The CPA/CPP Specification allows that parties agree upon a Collaboration Protocol Agreement (CPA) in order to transact business.   
TO: The parties can agree upon a Collaboration Protocol Agreement (CPA) in order to transact business.   


 Section 4.7

We are missing a major sub-section here that describes the use of
"BeginsWhen",
and "EndsWhen" and also the XPath expressions and the Variables
mechanisms, along with the ability to reference transactions and
modify the attributes dynamically for MSI - such as denoting
"TimeToPerform" and "Urgent", and so on.  We spent a huge
amount of time designing all that and getting it right - we need to
complete this critical section.  IMHO this one key mechanism is
what separates BPSS V2 from V1.xx - since it enables actual real
implementations to be built that interact with real payloads and
roles and context - eg real 3D - not just 2D models!!

I guess myself and John Yunker and Monica probably are on the
critical path to get that missing part tied down - or do we
already have something drafted on Variables from the last two
F2F work?

================
mm1: David, I think you may have missed sections. 
BeginsWhen, EndsWhen: Section 4.6.7.1
Variable usage: Section 4.6.8.1 

I agree we should put a specific note about use of condition expression, variable and TTP. Suggest in Section 4.6.8.1 as we  already make reference to use of external specification and talk about what a variable is.

[add prior to the last sentence in Section 4.6.8.1] In this version, the condition expression and variable functions allow assignment of the TimeToPerform value through the process lifecycle to enable late binding.  The TimetoPerform element MAY specify a duration and a type (for example, the value MAY be specified at design time). More requirements will be gathered to further understand the definition, use and other scenarios where variables may apply.

Also earlier in Section 4.6.8.1, correct the change of TTP to an element.

FROM: A fork has a timeToPerform attribute. 
TO: A fork has a timeToPerform element, where the duration may be specified.