Re: [ebxml-bp] Some design thoughts on documentcertifications/validation

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

intro: Let's step back a bit, please. The logical business document is 
there for loose coupling of different capabilities and separation of the 
actual messaging from the business process and related partner 
expectations. I'll try to answer where appropriate some of the questions 
raised or comments asserted. I encourage Dale to add herein. Thanks.

> Stephen,
> Excellent thoughts. 
>  
> The service/action pairs in the CPA capture the actual interactions 
> between partners - so for a given BPSS instance - there may be say 
> 30-something possible interactions - but partners agree on these & 
> service/action pairs from that superset that they themselves use.  
> This then is placed in the ebXML envelop header - so partners know 
> what type of transaction they are receiving.

mm1: Comment #1 See comments below on CPA v2.1 update.

> I guess the mismatch occurs originally because back in the early days 
> with Brian Hayes the BPSS V1x team made a decision to just deal in 
> logical business documents - and offload the actual document 
> resolution to a service - such as CAM. 

mm1: Comment #2 See initial comment in introduction.

> We've come to a more median point where we are allowing more specific 
> references - but we still require that actual runtime be resolved by 
> CPA and these external document services.

mm1: Comment #3 We do allow for semantic variables in the ebBP, and this 
would allow use of such external services. Although, I agree that the 
ebBP and CPA leverage one another (where appropriate).

> Hence version is less important - as opposed to the business notion of 
> the document - and a call-out to a service to resolve the actual 
> document.  Of course added to that is not just version but role and 
> context - and the CPA can definately supply those missing pieces. 

mm1: Comment #4. Callout to another service is at the discretion of the 
implementer, David. This is one option that is available.

> ........So in summary - my view is that the CPA - with the 
> service/action pair - marries to the BPSS - and then explicitly can 
> call out the exact schema / CAM / something to use when that 
> transaction exchange actually occurs between two partners.  
> Additionally this allows partners to configure exact version, role and 
> context information between themselves as needed.

mm1: Comment #5 The collaboration roles are supported in the ebBP v2.0.1 
and in the CPP/A v2.1. I am uncertain what explicit need exists to 
configure the role David. Condition expressions allow use of semantic 
information as well (specifically on the logical business document and 
activities).

>     green: I'm satisfied, personally, that where the requirement is
>     for a business process involving a UBL message payload
>     to be supported 'out-of-the-box' without any further
>     qualification (supported, that is, by the ebBP definition
>     and related CPP instances), if such a situation were
>     more than hypothetical, then things look OK. In practise
>     there is bound to be a requirement, I think, for further
>     qualification of what messages are to be supported by
>     the business process and/or the related CPPs and these
>     further qualifications, I think, will require more than can be
>     achieved with XSD files. Examples are enumerations of
>     codelists, definitions of subsets, etc. Take UBL, its codelists
>     and possible need for subsets for example but it was
>     pointed out yesterday that EDI message specifications
>     generally have such requirements.
>
>     Taking David's view that the latter need to be supported
>     more in the CPP and not necessarily in the ebBP definition,
>
mm1: Comment #6.
See Comments #1-5 and #7 (below). The technologies can complement one 
another (loosely coupled yet aligned). I think if we consider another 
optional attribute (in addition to location, targetNamespace [optional])

>     there seems to be a mismatch in the possible granularity
>     of what can be specified in the ebBP definition (with the
>     Specification elements) and the granularity of what can
>     be specified in the ebCPP/CPA (with the SimplePart).
>
mm1: Comment #7
See Comment #4-5. on the v2.1 update. The latest public version can be 
located at: 
http://www.oasis-open.org/committees/document.php?document_id=12208&wg_abbrev=ebxml-cppa.

There has been another update since that time and transport changes are 
also under consideration in CPP/A to handle anticipated ebMS v3.0 
changes. No mismatch AFAIK [1]. Please ask Dale for the updated version 
(August 2005 + updates) For example, see transport discussions on public 
email archives such as 
http://lists.oasis-open.org/archives/ebxml-cppa/200509/msg00001.html.

[1] given the two co-chairs for ebBP includes CPA chair....:>)

>     It is actually, it seems, the latter which offers less granularity.
>     The former allows use of XSD, Schematron, DTD, RelaxNG
>     and 'other' (prose, etc). The latter doesn't overtly support,
>     it seems to me, anything except XSD. 
>
mm1: Comment #8.
See Comment #7. This is no longer a constraint.

>     Both provide the means  to specify a namespace and a location.
>     Another mismatch is
>     that the CPP also allows specification of a version identifier.
>
mm1: Comment #9.
The CPP specifies the Process Specification references, Stephen so I may 
require clarification of your question. Dale can provide some examples 
he's been working on showing how various protocols (AS2, EDIINT, etc) 
would be used in CPPA in addition to other process characteristics. 
Extensions exist in v2.1.

>     It would be nice if these could be aligned or just one or the
>     other specified as the primary place to specify the artefacts
>     which together define the message parts (including the
>     payload).
>
mm1: Comment #10
See Comment #7.
The two specifications can work in a complementary fashion and have 
distinct functions, Stephen.  The process specification references in 
CPP/A specify the business transaction characteristics in the contex of 
the process definition. The document exchange specifies the physical 
processing of the actual business documents by the Message-exchange 
function (such as ebMS, AS2, etc).

>     More than nice is still the urgent need, I think, to extend
>     either one or the other to cater more fully for * both *
>     the location and a more formal identifier of * each *
>     artifact in a message payload without limiting such
>     artefacts to just XSD (change to ebCPP? or change in view
>     of role of ebBP?) * and *, in line with this, without limiting
>     the identifiers of such artefacts to just something which
>     can properly be called a 'namespace'. Without this I only
>     see ebXML being used to specify messages for just systems
>     which can cater for all sorts of eventualities where XSD files
>     and their namespaces and locations provide sufficient
>     information granularity to limit the specification of an
>     acceptable message payload.
>
mm1: As we discussed as an option on Monday, an additional attribute 
could be considered to provide an identifier. That way we can serve 
communities using different models/modes of exchange. This has been a 
premise for v2.0.1 ebBP as well as CPP/A v2.1 (where the complements 
have pretty much been in lock step).

Thanks.