[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]
Powered by eList eXpress LLC