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

Woah!  I apologize, but I didn't understand a word of this response.  I
guess I'll have to give that GUIDE spec a close read.  I understand some of
the problems of trying to make use of the X in XML, and it would be great
if we had something that helps to mitigate them.

- Joe

At 09:20 PM 8/4/00 -0400, 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.
>The reason being is that there is NO master message definition, since
>the namespace used as an included which is itself part of the XML means
>it is impossible to know what the actual header construct is, without 
>inspecting an message header document instance!
>In GUIDE this is explicitly excluded by using the GUIDE structure layer
>to explicitly define the structure, and therefore avoiding any nested 
>parsing complexities due to unresolved content.
>Therefore a GUIDE structure defining the message header would be
>extensible but in a predetermined and controlled way - and of course
>that is exactly the guarantee we need for interoperability.
>Thanks, DW.
>p.s. More info' on the GUIDE structure layer mechanism for 
>        http://www.bizcodes.org/GUIDE/

[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