|
Hima:
Here are my preliminary examples. It does include instances of
the NonRepudiation and DigitalEnvelope elements. Please let me know
what other changes/improvements you like to see.
Thanks,
-Arvola
I don't know the PIPs which Arvola is
going to include, but I'd like to see
some Service and Action BIndings
related to security, preferably one for
non-repudiation, one for secure
transport and one for Digital Envelope.
I volunteer for that, if Arvola is not planning for these. I have
some working
samples against the DTD version of CPA schema which I'll have
to move
to schema version.
-hima
Dale Moberg wrote:
Hmmh. OK, it might be nice to
show the more complex example with two bindings in
it.Any other
reactions?The worked out RN
exampleshould 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
nowbecause XMLDsig schema (which
we cite) is not up to date with respect to the schema
standard!Dale
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
changesafter
us? Possibly if we simply include
a disclaimer thatthe 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 versionwere used. Maybe,as long as we don't say itis normative it would be
OK. I will ask Karl Besgt how any
such referencesto unapproved (not yet approved)
standardsare 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
asynchronoustransport capabilities
only, and a contrasting CPP with a PartyInfo for
synchronous?)Dale
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
|