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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

 

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