RE: [R6xx, R7xx] Application of XP requirements to SOAP 1.1

> That is possible for XML data that uses the id/href mechanisms for
> reference. But this is not _explicit_ in the text of the SOAP 1.1
> document, it is up to the reader to _assume_ that this is the case.
> So it doesn't really address it IMHO :)

I see

>> Ie is correct that it doesn't say
>> how to carry data outside the envelope but in fact SOAP itself doesn't
>> even say how to carry itself. This is where the protocol binding model
>> comes in.
>
>I don't think these points are actually related, Henrik! :)

Given your clarification I agree

> Standard semantics for certain failure modes that are relevant within
> the standard SOAP processor architectural artifacts are necessary for
> definite. Mapping of these failure modes to transport protocol failure
> modes, should they be supported is necessary in the transport protocol
> bindings. Extension is required for application specific and
> proprietary
> extra information or finer grained failure semantics. Er, I'm agreeing
> with you here...

:)

>>> R701a - single schema-defined container for messages
>>>
>>> The SOAP 1.1 Enveloping scheme satisfies this requirement if taken in
>>> isolation. Given the context of other XML Protocol requirements and
>>> the context of binary content discussions, the SOAP 1.1 scheme may
>>> only partially satisfy this requirement.
>>
>> I don't follow you here?
>
> An assumption on my part that schema-defined means XML Schema defined
> that means XML container (rather than say manifested
> multi-slot container).
> I'm not a schema expert so this may be incorrect.

I still don't follow :( SOAP current has a model that defines the SOAP
envelope with a schema and each "XML protocol block" has may have its
own schema but they don't have to be related in any way. Is this what
you are referring to?

>>> R701b - processing model
>>>
>>> Is only slightly addressed by the concept and categorisation of faults
>>> and so is not satisfied by the SOAP 1.1 specification.
>>
>> I don't understand what you mean by "slightly" - there are specific
>> fault codes for fault cases that directly are a result of the basic SOAP
>> processing? There are of course not fault codes for anything else.
>
> XML Protocol will have a richer processing model and it
> appears that we
> will also generate at least a notional processing
> architecture. SOAP 1.1
> has faultcodes 'Server' 'Client' 'VersionMismatch' and
> 'mustUnderstand'.
> This reflects a simple processing model that will not be rich
> enough for
> XML Procotol, IMHO.

Could you please give me an example - I am not sure what you mean.

> I shouldn't have said HTTP here, sorry! What I meant was SOAP
> 1.1 has an
> implicit dependence on synchronous request reply transport protocol to
> achieve request/reply/fault correlation.

SOAP walks a fine line here - it defines faults but in fact doesn't say
what to do with them. It doesn't say how or even if faults are to be
"returned" as SOAP proper doesn't really know what that means.

Once you slap an HTTP binding on it, SOAP says that it makes sense to
return the fault in an HTTP response but other mechanisms may be
available for SMTP bindings for example.

>>That depends - SOAP leaves it up to the application to define what
>>status information os. For example, SOAP doesn't care if you send a
>>purchase order and get back a "thank you we are working on it" message.
>>The only thing that it does care about is whether it is a fault. So in
>>the sense that one can stick (in theory) any data into a SOAP message
>>then why wouldn't status information be part of that as well?
>
>Ah yes, if you have an extensible protocol you can make
>anything of it :)

Exactly!

> BUT what I was addressing was an _explicit_ conventional approach to
> transferring status information, which is the thrust of R703b.

I am not arguing that it might be useful - I am arguing that it is hard
to talk about status information without talking about a context. For
faults we have a context, which is the SOAP processing model but for
status I don't think we do.

Maybe it would be constructive if you can give me some examples of what
you mean by status information?

>> SOAP is fundamentally a one-way message so it doesn't know about
>> correlation and therefore doesn't really have an implicit dependency on
>> a request/response protocol. Of course, what you get when you use a
>> request/response protocol is some kind of correlation but there is there
>> a reason why one couldn't do that as a SOAP header (XML protocol
>> module)?
>
> If SOAP is one-way, then it should not have an RPC convention, or it should
> at least say this and explain the semantics. This is why I argue that
> SOAP1.1 has a dependency on certain transport protocol features.

Well, I think one can imagine putting many different message exchange
pattern in SOAP but I agree that it could be explained better than it
is.

> I think the problem
> here is because the SOAP 1.1 note does have a number of
> interpretations in
> the details - purely because it hasn't suffered the slings
> and arrows of
> a large committee based standardization process ;)

Yeah - maybe we should fix that some day ;)

> Rather than bash my assumptions off yours, we will need to get this
> fixed in the XML Protocol definition!

The reasons for my questions is not to bash your assumptions but rather to
understand where you are coming from and understand your point of view.

>> As there effectively is a binding for HTTP to SSL then wouldn't the SOAP
>> binding to HTTP be sufficient?
>
> Ummf - I don't know without further thought and analysis as I have a very
> basic SSL operation knowledge. Anyone else for this one?

I would carefully claim that it might be sufficient for at some purposed ;)

Henrik

Received on Wednesday, 31 January 2001 19:28:53 UTC