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 <dmoberg@cyclonecommerce.com>
- To: David Fischer <david@drummondgroup.com>,ebXML Msg <ebxml-msg@lists.oasis-open.org>
- 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