[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]