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.

I have been using the CPA and not restricting the URL to just XSD but actually referencing CAM templates for those business transaction validations. I believe the CPA supports this - and obviously it works!

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

Overall I do not see this as broken - and we have definately been coordinating significantly with the CPA team to ensure things work and align.

The devil is as ever in the details however - so we do need to be clear and document how we expect this to work and for implementers to follow a set of clear guidelines for sensible use patterns.

Hopefully we are closing in on that overall understanding here!

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.

Now the exact XML details of that are a little harder to nail down - but conceptually - that is the model I believe is implicit here. Dale and sure can provide further insights from the CPA trenches.

Cheers, DW

-------- Original Message -------- Subject: Re: [ebxml-bp] Some design thoughts on document certifications/validation From: "Stephen Green" <step...@bristol-city.gov.uk> Date: Wed, October 05, 2005 10:38 am To: <ebxm...@lists.oasis-open.org>

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, 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). 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. Both provide the means to specify a namespace and a location. Another mismatch is that the CPP also allows specification of a version identifier.

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

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.

All the best

Stephen Green

>>> "David RR Webber (XML)" <dav...@drrw.info> 04/10/05 18:33:15 >>> Monica,

Just wanted to share some thoughts on overall design WRT this functionality - and especially with things like codelists, versioning and business intent / legal intent.

I'm not sure we envision the BPSS itself being able to handle all those aspects standalone!?!

For example - the legal aspects of binding to specific documents - that to me is more the role of the CPA and MoU rather than the BPSS instance, so we'd expect people wanting those parts to be using those mechanisms to augment BPSS.

The BPSS either can have support for

1) a runtime service - such as registry, schema, CAM, schematron - that would provide that binding to the physical rules being applied - and then the implementor is responsible for ensuring that trading partners are using the right rules. 2) design time reference to human readable documents that detail specifics (these tend to be by their nature more open ended than a machine processable rule set)

So I think that should clarify things here more easily. E.g. would we want people to view the UBL schemas, schematrons, web-based readable docs and BPSS instances as the sole legally binding artifacts in defining a business agreement between two partners?

I believe in most instances we would want that to not be the case - individual trading partners should agree within themselves and their community. That is certainly the current practice I see out there today - where they pick a version and all align to that - and separately instance legal agreements- PIDX have certainly followed that path just as one example of an ebXML community.

Also registry of course provides a compelling deployment model - and ebSOA is definately projecting that - where participants can do a variety of services thru that to coordinate their implementation across a community. In terms of promoting adoption of BPSS and UBL I would see a registry service as an enabler - not an impediment. Whereas one-off users may eschue the registry - and serious long term community must see the inherent value, that would be difficult to do using just URNs alone.

The XML2004 Interop obviously points to how this can be delivered in a government context, such as the EU, or a state or local government office. http://ebxmlbook.com/interop and right now we are in fact developing this infrastructure for the government project I'm directing.

Just some thoughts here as we seek to refine the use cases we want to foster, while enabling people to also easily discern a simple use of local one-off deployments that are not too burdensome to figure out - lessons learned tell us we need that simple and obvious approach too!

Thanks, DW