[no subject]

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.

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.

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

Line 354 /355 - current order works for me - why are we thinking otherwise?

Line 364 - multiparty... - involve two or more roles and more than two
participants.

Line 371 to 377 are too obtuse - can we give a concrete example?

Line 379 - formatting.

Line 408 - typo - fails from a protocol perspective
Line 409 - typo - prior to
Line 410 - typo - In the case of

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

Line 421 - change to - Notification (or Notification of Failure (NoF))

Line 433 - responding parties performing roles.

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

Line 437 - typo - acctual

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.

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.

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

Line 521 - this involves steps 1 through 3 above.

Line 524 - spelling - example.

Line 565 - typo - a an

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.

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.

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

Line 678 - typo - remove "is".

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.

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

[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

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?

Thanks, DW