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

From
System
Date
2002-01-05T09:36:00+00:00
ID
Thread
RE: [ebxml-msg] Messaging Spec v1.092
MHonArc v2.5.2 -->
















ebxml-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








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




From: Dale Moberg <>
To: David Fischer <>,ebXML Msg <>
Date: Sat, 05 Jan 2002 07:32:00 -0700









 
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












[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC