RE: [ebxml-cppa] Updated schema with annotations to motivate therecentchanges

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Arvola,

 

I think those are excellent examples to have to

illustrate how the specifications hang together.

Will using the BPSS instance cause any problems

since they may submit their changes

after us?

 

Possibly if we simply include a disclaimer that

the BPSS schema/dtd referenced is

not necessarily the most current...

However, it would be best if

the possibly not yet approved

schema for the BPSS version

were used. Maybe,

as long as we don't say it

is normative it would be OK.

I will ask Karl Besgt how any such references

to unapproved (not yet approved) standards

are to be handled.

 

Any other thoughts from anyone?

 

 

 I like including both CPPs.

 

Would we benefit from having 3 CPPs to illustrate how

two pairs of CPPs support the  two CPAs?

 (That is, one  CPP whose PartyInfo has asynchronous

transport capabilities only,

and a contrasting CPP with a PartyInfo for synchronous?)

 

Dale

 

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Monday, December 10, 2001 6:25 PM
To: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] Updated schema with annotations to motivate the recentchanges

Attached please find another version of the updated schema that includes annotations explaining the recently proposed changes.

 

I like to submit the updated CPP and CPA examples once we have agreed on the schema changes. For completeness, I like to include a BPSS instance that is referenced from the CPP and the CPA, using RosettaNet's PIP3A4 as an example.

 

In fact, rather that including just one CPP, I like to include a CPP for each of the two parties whose collaboration agreement is documented in the CPA.

 

Within the CPA, I like to show two service bindings, one using synchronous response and the other using asynchronous response.

 

-Arvola