Some design thoughts on document certifications/validation

ebxml-bp message

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

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.

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!