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

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

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)" <david@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