Re: ebXML PoC -- feedback to working groups

[Christopher Ferris - XTC Advanced Development <chris.ferris@east.sun.com>]

Comments below. Great job in pulling together the
nearly universally acclaimed demo in Tokyo. I for one
thought that it kicked butt! I've heard nothing but
positive comments from all who saw it.

Cheers,

Chris

Philippe DeSmedt wrote:
> 
> All,
> 
> At our post-PoC planning meeting in Tokyo, I was asked to coordinate the
> feedback from the PoC team to the various working groups.
> 
> Let me summarize what I have heard so far:
> *       the lack of precise specifications for multi-hop messaging caused
> some confusion; in particular, acknowledgements cannot currently be sent
> back to the original sender using the path (through the hub) that the
> original message took, but rather, the acknowledgement is sent back directly
> to the sender: the reason is that there is no place in the header to keep
> that information; furthermore, there are various interpretations as to what
> the acknowledgement should convey, i.e., received at the next hop, or
> received at the final destination;
> resolution: this has been brough to the attention of the TR&P working group,
> which is currently taking on the specifications for multi-hop messaging;

I believe that the confusion lies in the fact that TR&P had excluded
multi-hop functionality from the RM spec incorporated into the MS0.21d
specification specifically because there was not agreement within TR&P
as to how best to approach the problem. The fact that the POC decided
to include a hub in the demo resulted in the confusion (IMHO). 

In hind sight, we (TR&P) should probably have made it clearer
in the spec that the multi-hop feature was excluded so that
it could be further investigated/revised from the original
proposal.

I think that this also points to the issue of having a firm
specification underlying *anything* demoed by the POC. If it isn't
in the spec, it shouldn't be attempted. ("don't try this at home"
comes to mind;-) It is my understanding that Nick intends to 
take a harder stance on this for any future POC demos.

> *       optionality is a problem: some of the fields in the header are
> specified as optional (e.g. RefToMsgId (sp?)); optionality greatly decreases
> the likelihood of out-of-the-box interoperability;
> resolution: this has been brought to the attention of the TR&P woking group;
> they will look carefully at all of the fields (current and future) that are
> optional;

I thought that I understood that the issue was more of one
regarding clarifying the distinction between "optional to implement"
and "optional in cardinality or use within an instance". It is
also my understanding that the resolution was to be that
we would scour the spec for cases where there is an "optional"
element in the DTD/Schema and reinforce the language used to
make it expressly clear as to the expected/required handling
of an "optional in cardinality within an instance" element
in its absense. In additon, if an element is "optional to implement"
such as SequenceNumber in the RoutingHeader then clarifying
language will be added to the specification as to the
expected/required treatment as well.

We (TR&P) will endeavor to minimize the optionality within
the spec/protocol, but reserve the possibility that it be
necessary to allow for elements with cardinality requirements
of 0 or more.

> *       default values can be a problem:
> resolution: the TR&P group suggested that we look at the latest spec (0.8),
> as the number of attributes with optional values has been reduced;

I think that you meant default values, and yes, I believe that
we have eliminated all by the xmlns and Version attributes as having
default values.

> *       I know that Hatem and his team have a number of issues that they
> want to bring up (Hatem: could you please make that list available to the
> mailing list? Thanks much!)

Yes, please do! The sooner the better as time is precious.

> 
> Please let me know if there are any issues that I have missed, or if there
> are new ones that you have thought about. It is important that our feedback
> gets communicated to the various working groups. So far, comments seem to
> pertain to TR&P. Are there any other groups that we have feedback for? TP?
> Reg/Rep? ...
> 
> Thanks.
> 
> -Philippe
> _______________________________
> Philippe De Smedt
> Architect
> Viquity Corporation (www.viquity.com)
> 1161 N. Fair Oaks Avenue
> Sunnyvale, CA 94089-2102
> (408) 548-9722
> (408) 747-5586 (fax)
> pdesmedt@viquity.com

-- 
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development 
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903