Re: mustUnderstand reformulation

 Noah, Glen, you wrote

 > Elements tagged with the SOAP mustUnderstand attribute with
 > a value of "1" MUST be presumed to somehow modify the
 > semantics of their parent or peer elements

 I'd like us to consider this from the implementor's point of
view. Your proposal would have to be implemented similiarly to
the following (let's assume some programming language similar to
Java):

    // do mustUnderstand check
    mUHeaders = selectMUHeaders(allHeaders);
    foreach h in (mUHeaders) {
        handler = findHeaderHandler(h);
        if (handler == null) throw MustUnderstand fault;
    }
    // do mustUnderstand semantic changes
    foreach h in (mUHeaders) {
        handler = findHeaderHandler(h);
        handler.doMUSemanticsChange();
    }
    // do header processing
    foreach h in (allHeaders) {
        handler = findHeaderHandler(h);
        if (handler != null)
            handler.doHeaderHandling(h);
    }

 The problem I see is with the order of the second and third loop.
The first loop does no actual processing so the order is
irrelevant.

 Suppose we have two mU headers which imply the semantic of
"process-me-first". Such a semantic could be implemented simply by
making the function doMUSemanticsChange change the order for the
third loop. How do we find out that there is a conflict? Anyway,
there is still the problem of the ordering of the second loop.

 What I see as the simplest solution to such mustUnderstand
processing would be:

 1) check whether you know how to handle the QNames of the headers
marked as mustUnderstand, if you find a QName, generate a fault.
 2) process the lexically first header. Such a processing could
impact further processing model. In case of no such impact,
process the lexically next header. Wash and rinse. Repeat as
needed.

 Let me now consider the impact of this on solving various
situations (as opposed to solving them with processing model that
doesn't by default specify any processing order):

 a) in case where the order of processing is not significant, the
client can generate the headers in any order and the server can
process them in any order. If we impose ordering on the server, it
can be viewed as an unnecessary constraint because otherwise the
server would be able to optimize the order.

 b) in case where the order of processing is significant, the
client has a choice:

       b1) either put the headers in the order,

       b2) or insert to the front a header that specifies the order.

   In the no-order-processing-model case the client would always
have to do b2.

 c) in case where the order of processing is significant but the
client is not able to insert the proper header in the front of the
message because it doesn't have enough data to do that, it would
have to insert two headers:

       c1) a mU header in the front that says "first process the
header that changes the ordering"

       c2) a header (anywhere) that does, indeed, change the
processing.

   In the no-order-processing-model case the client would have to
insert only one header whose mU processing model change semantics
are that it is processed first.

 To summarize the impact of my proposal:
case a) may require additional headers,
case b) may result in saving a header,
case c) does result in an additional header.

 I haven't considered much the case of a constrained server because
I think we favor simplicity and clarity over the possibility of
streaming.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/

Received on Thursday, 16 August 2001 07:33:00 UTC