Dale,
You said: "Do you want to write the MSH so CPPs
and CPAs cannot be used? If so, there will be several
annoyed people who have worked on tracking all
of Messaging's meandering and providing all the items
needed for agreements for ebXML messaging parameters."
Doing this is worse than annoying. You could write an MSH spec that would
not need CPPs and CPAs. It wouldn't even need manual configuration entry.
It would have to dynamically negotiate every item in the CPA at the
beginning of an instance of communication between the two partners. That's
probably the antithesis of dynamic e-business. In any case, it would be
almost a completely separate implementation and anyone who needed to work
with and without CPAs would need both.
The MSG team would get a lot closer to "CPA-independence" if they would
clear up the ambiguities as to whether certain items are in the CPA or
message header. They might also clear their heads if the would adopt my
definition of "CPA": "Configuration Parameter Aggregation" :-)
Keep swinging.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown
Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
Dale Moberg <> on 01/05/2002 09:32:00 AM
To:
David Fischer <>, ebXML Msg
<>
cc:
"Ian. C. Jones (E-mail)" <>
Subject:
RE: [ebxml-msg] Messaging Spec v1.092
David Fischer writes:
�"�I�want to thank everyone for all the help on editing/reviewing the
specification.� I think this is a much better spec than v1.0.� That said,
I will also say I plan to vote *no* on this spec for two reasons:� 1) Our
charter was to create a v1.1 spec with "fixes and clarifications only"
which we have failed to do (if we could�name�this spec v2.0, as the RegRep
team did, then this objection would go away),� and� 2) Our original
charter was to create a set of "orthogonal ebXML specifications" which we
have failed to do (we have tightly coupled Messaging with CPPA).� I would
like to urge everyone to consider a version number of v2.0 since v1.1 has
the connotation of backward compatibility which we certainly have not
achieved.� Our next version could then be v3.0?�"
David,
Two brief comments:
1.�RosettaNet 1.1 is not backwards compatible with 1.0.
There is�a�precedent for� a minor version renumbering being
backwards incompatible with its predecessor.
My impression is that ebXML is mainly
a pilot-only installed base, and there is little serious
production traffic.�That means it not much of a practical
shortcoming to give up backwards compatibility,
just annoying to implementors and vendors.
I also think that� the changes have� really been fixes
(or deletions when fixes could not be agreed upon)
and clarifications; I do not see that loads of new
functionality has been introduced. We haven't added
checkpoint-restart or forward-progress indicators or
whatever, but just reworked things for clarity and a
better fit with SOAP conventions. I would prefer
to see a major version change mark introductions
of significant new SOAP "modules"� myself.
2. What dependency of Messaging on CPPA�specifications exist?
Does a MSH have to export CPPs or import CPAs? No.
If a CPA instance document does not exist, is ebXML messaging
impossible?��No. CPP or CPA instance documents are
not required as either inputs or outputs of a MSH.
If a MSH could not work without a CPA, then
they wouuld be tightly coupled. I think your objection
is mistaken. Do you want to write the MSH so CPPs
and CPAs cannot be used? If so, there will be several
annoyed people who have worked on tracking all
of Messaging's meandering and providing all the items
needed for agreements for ebXML messaging parameters.
Dale Moberg
