Re: [ebxml-bp] ebBP 2/4/2005: Webber Questions (part 2 of 2)

["David Webber \(XML\)" <david@drrw.info>]

Monica,

OK - once again - good choices on the review items.

I'm happy with outcomes and items for review as indicated
by you here.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Sunday, February 06, 2005 7:18 PM
Subject: [ebxml-bp] ebBP 2/4/2005: Webber Questions (part 2 of 2)


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