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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Hmmh. OK, it might be nice to show the more

complex example with two bindings in it.

Any other reactions?

 

The worked out RN example

should be OK. I will still check with

 Karl on how to handle any linkage of references.

The BPSS 1.0 version was DTD only, as I recall.

I get complaints from developers now

because XMLDsig schema (which we cite) is

not up to date with respect to the schema standard!

 

Dale

 

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, December 11, 2001 9:37 AM
To: Dale Moberg; ebxml-cppa@lists.oasis-open.org
Subject: Re: [ebxml-cppa] Updated schema with annotations to motivate the recentchanges

Dale:

 

I was hoping to borrow or adapt one of the BPSS instances that RosettaNet has used to model one of the existing PIPs (as used in an earlier validation test), based on the 1.0 BPSS specification.

 

Instead of having two CPA's, I was planning to use one CPA but two service bindings within the CPA. Is it possible that two trading partners may want to use the asynchronous response mode if the request is expected to take a very long time, and to use the synchronous response mode for a similarly structured request that can be expected to be processed instantaneously? Alternatively, I can use two different business processes, one requiring synchronous response and the other asynchronous response.

 

Anyway, I am open to suggestions on how to structure the examples.

 

Regards,

-Arvola

-----Original Message-----
From: Dale Moberg <dmoberg@cyclonecommerce.com>
To: Arvola Chan <arvola@tibco.com>; ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, December 11, 2001 8:15 AM
Subject: RE: [ebxml-cppa] Updated schema with annotations to motivate the recentchanges

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