RE: [ebxml-msg] Messaging Spec v1.092

[Martin W Sachs <mwsachs@us.ibm.com>]

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 <dmoberg@cyclonecommerce.com> on 01/05/2002 09:32:00 AM

To:    David Fischer <david@drummondgroup.com>, ebXML Msg
       <ebxml-msg@lists.oasis-open.org>
cc:    "Ian. C. Jones (E-mail)" <ian.c.jones@bt.com>
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