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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: Re: More: Now some feedback on Header v0-63

Aye, but people will extend the protocol, even if it is "dangerous."  We
should probably do what we can to minimize the interoperability pain.  The
least we can do, whatever the mechanism, is to say how one should go about
extensions.  This should help to minimize the potential anarchy.

I used the term "extensions," but I mostly mean to include out-of-band data
that middleware needs to communicate.

And not all extensions need be dangerous, provided that some rules exist
for how to ignore unrecognized data.  We just need an escape mechanism.
Without these rules, any extension will be dangerous, since if an extension
is present, some implementations may throw non-conformance errors, while
others won't.

But I'm going to read the GUIDE spec to see if I can get a grip on what
problem it is trying to solve and how it solves it.

- Joe

At 11:43 PM 8/4/00 -0400, Christopher Ferris wrote:
>David RR Webber wrote:
>> Message text written by Joe Lapp
>> >The BizTalk/SOAP approach is to require that every child element belong to
>> some XML namespace (that every header entry belong to some namespace).
>> That way a middleware app can identify its own headers by namespace and
>> ignore everything else.
>> <<<<<<<<<<<<<<<
>> Joe, this is a very dangerous mechanism if not controlled and used
>> correctly.  The way Microsoft uses it in XDR is rightly labelled as
>> highly dangerous.
>I agree.

[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