OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: ebXML PoC -- feedback to working groups


Philippe,

During the last POC there were a couple of packaging related issues. Have
all the packaging related issues been resolved?

Kudos to everyone involved in the POC. Your demonstrations neutralize the
FUD and build public confidence in ebXML.  High-5 to all of you!

Thanks,



Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Philippe DeSmedt [mailto:PDeSmedt@viquity.com]
> Sent: Tuesday, November 14, 2000 1:49 PM
> To: Ebxml-Poc (E-mail)
> Subject: ebXML PoC -- feedback to working groups
>
>
> 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;
> *	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;
> *	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 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!)
>
> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC