Re: [ebxml-cppa] The importance of the CPA

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Sacha Schlegel wrote:

>Hi CPPA team
> 
>Working with a real world commercial ebXML system it becomes obvious that the CPA becomes a very very important document for runtime. The ebXML Message Service Handler runs based on information found in the CPA. If ebXML collaboration systems support collaborative business processes, they will use the ProcessSpecification element of the CPA. So the CPA is the central document for the ebXML runtime environment.
> 
>To me the current most important job is to make sure that a CPA instance is correct.
> 
>It is not sufficient that the CPA passes the ebXML CPPA schema validation.
> 
>I start to call these additional test "CPA integrity" tests.
> 
>o One example is, that the value of the OtherPartyActionBinding must be present in the other party Info element as a ThisPartyActionBinding.
> 
>Was there ever an intention of this TC to have other normative deliverables than the CPPA schema?
> 
>I think of normative Schematron rules. Or is the intention to leave this to the implementors. A public place for core normative "CPA integrity" rules would foster ebXML collaboration systems interoperability.
> 
>What do people think?
> 
>  
>
Hope you dont mind an observer to respond.

Such validation rules are exactly what can be enforced when the CPA is 
maintained within an ebXML Registry. The registry supports Content 
specific validation of arbitrary content via pluggable Content 
Validation Services.

I have long hope that the CPPA team would define a TN titled something 
like "Managing ebXML CPP/A in an ebXML Registry". Such a TN would 
describe the specific validation rules that must be enforce when a CPP/A 
is submitted to the registry. A CPP/A Validation Service could be 
defined using the TN and registered with the ebXML Registry. When 
someone submits a CPP/A the registry automatically runs it through the 
CPP/A validation service and decides whether it passes or fails. If it 
fails then the request is rejected. If it passes then it is stored in 
the registry.

Another thing the TN could describe is CPP/A Cataloging Service. Such a 
Service would automatically convert selected CPP/A content into 
metadata. For example, it could look at the <cpp:Role> element (not sure 
if that is still the right name) and use it to automatically classify 
the CPP as Buyer, Seller, Intermediary or whatever based upon a 
canonical ClassificationScheme specified by the same TN.

The TN could also describe standard parameterized stored queries such as:

-Find me all CPPs for Buyers that support specified BusinessProcess.

If all this was defined in such a TN then a project like freebXML 
Registry could support the TN functionality out-of-the-box within the 
ebXML Registry or as a pluggable module.

The neat thing about all this is that the ebXML pieces work together 
where the Sum of parts is greater than the whole.

-- 
Regards,
Farrukh