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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

See comments in line. But with this initial
premise: the "independence" that we seek
in each ebxml specifications is not like
political independence or sovereignity but
more like logical independence. The idea
of logical independence is that either
including or omitting some item is consistent
with some target module. For example, the
parallel postulate is independent of euclidean
geometry core axions because it can be consistently
added to them or consistently omitted from them.
Thus, I do not take independence to mean that
Messaging stuff can be used with or without
CPPA stuff. Previously, people have commented
that Messaging clearly can be used without CPPA stuff.
Can it be used with it? I think David wants to make
it difficult to use CPPA with it.

DF= David Fischer

DF>I disagree.  If the specs were truly loosely coupled then we would
not have
discussions concerning discrepancies between the header fields and the
CPA.

Those discussions are concerned with using CPA _with_ Messaging-- to
make
certain Messaging can work the way it is specified and people _can_ use
a CPA.


DF> Errors concerning such discrepancies would be implementation
dependant.

Well, make them so. I wonder how that will promote interoperability.



DF>We would not worry about aligning Messaging and CPA. 

DM> So the CPA can fail to specify parameters needed by a CPA? And
they will "work" together? The alignment is mainly of CPA with
Messaging, not the other way around.

DF>We would not have continual
problems with having to remove fields from the Messaging headers because
they
are already specified in the CPA (in fact, many fields would exist both
places).

DM>I think you would have to have a coherent basis for deciding what was
to
be in the header and what what just configuration no matter whether
there
was a CPA or not. You simply forget that before we had even introduced
CPA, Drummond and many others were strongly arguing that David Burdett's
list of headers was severely bloated, or, with reversed bias, 
comprehensive. The CPA stuff emerged as a _solution_ to this problem
Those who forget history...

Several fields do exist in both, and there is a mechanism for indicating
that header values rule. Anytime a consensus forms on putting something
in the header, it can be adopted. 

DF>We even voted at the last F2F that there MUST be an agreement in
place -- no
allowance for spontaneous eCommerce.  There has been constant discussion
that
there MUST be either a CPA or a "virtual CPA", which simply means a
database
containing all the CPA fields and structures even though there may not
be an
actual XML document anywhere.  Quotes from the spec to the contrary are
simply
my lack of diligence in removing them since the last F2F.

DM> David,  now you are drifting away from independence and into
something else.
Marty has explained that use of agreements will become consistent with
use
of CPA templates etc. This is a provisional state of development that we
do not have an automatic negotiation protocol done yet. Also, there
is a "solution" that already develops this angle (SOAP+UDDI+WSDL). Why
should we reinvent this? 

DF> If we could move back to a time when we did allow non-agreement
(with or without
CPA) type eCommerce, then that would remove my objection -- but I don't
think
that is where we are now. 

DM>So, the objection really isn't to CPA stuff? OK moving on...

DF>Our original charter was to focus on the SME needs in
eCommerce. 

DM> I understood the interest to be in not ignoring the SME needs, not
focus on them. If the SMEs cannot talk to non-SMEs the spec
would have limited value. Presumably, the nonSMEs have more complex
environments while SMEs can get buy with a very restricted subset.


DF>I would argue the SME's need something more akin to B2C rather than
traditional B2B (I don't mean Web based but I do mean spontaneous). 

Possibly. I am very uncertain what the SME market needs or wants in
detail.
For all we know, they want it all to come in on their fax machine. Where
are the detailed, empirically supported, studies of this alleged market
and its interest in automating business processes? 

DF> My objection is that our (very good) system is largely a rehash of
what has gone
before (and maybe somewhat of an improvement) but it does NOT adequately
address
the needs of SME's.

Actually, I agree with this. But I would think it would be a good reason
for abstaining from lack of interest, rather than vote against.

DM> I would like to see a clear definition of these needs, backed up by
extensive
informed statistical surveys (that is, not marketing or analyst group
stuff)
to show that these are the needs of these SMEs. We never had this
information,
and we still don't.

DF> Now, someone else please take the SOAP box  ;-)

DM> This comment intentionally blank.