Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] Request For Clarification

Expand Messages
  • Andrew Layman
    My reading of SOAP 1.1 section 7 does not say that the struct representing the method invocation or response would be the first child element of the body. In
    Message 1 of 62 , Apr 16, 2001
    • 0 Attachment
      My reading of SOAP 1.1 section 7 does not say that the struct representing
      the method invocation or response would be the first child element of the
      body. In the case of parameters which are or have multi-reference values,
      this leaves open the possibility that the first element is not the struct
      representing the method invocation or result.

      Clearly, some additional information is needed.

      Here are three possibilities that I see for solving the ambiguity:

      1. If one has a WSDL file describing the method invocation, then that
      WSDL file, not a method signature, acts as the metadata for the method to be
      invoked. As such, it can declare the rules more tightly.

      2. We might agree on a convention regarding which element expresses be
      the method or response value. In this case, we would need to invent a new
      encodingStyle URI.

      3. SOAP actually provides an attribute intended to resolve this sort of
      problem. Frankly, I think the description of it wins an award for obscurity.
      I'm thinking of section 5.6 defining the SOAP "root" attribute:

      "The SOAP root attribute can be used to label serialization roots that are
      not true roots of an object graph so that the object graph can be
      deserialized. The attribute can have one of two values, either "1" or "0".
      True roots of an object graph have the implied attribute value of "1".
      Serialization roots that are not true roots can be labeled as serialization
      roots with an attribute value of "1" An element can explicitly be labeled as
      not being a serialization root with a value of "0".

      "The SOAP root attribute MAY appear on any subelement within the SOAP Header
      and SOAP Body elements. The attribute does not have a default value."

      I believe this says that, in the serialization of a graph containing
      multi-reference values, one may place an attribute like SOAP-ENC:root='0' on
      elements to declare that they are not, in fact, the element representing the
      method invocation or response.

      Here is an example from the specification hacked up to place a value before
      the method response and mark it with root='0'.

      <SOAP-ENC:int id="i1" SOAP-ENC:root='0'>34.5</SOAP-ENC:int>
      <LastTradePrice href="#i1"/>

      ----- Original Message -----
      From: "Simon Fell" <soap@...>
      To: <soapbuilders@yahoogroups.com>
      Sent: Sunday, April 15, 2001 11:23 AM
      Subject: [soapbuilders] Request For Clarification

      This is an issue that's come up a couple of times[1,2,3] over the last
      two or three weeks, each time there's been no conclusive outcome, I
      was hoping that Andrew and/or Henrik could voice their opinions.

      Basically the issue is, when doing section 5 encoding with section 7
      RPC, is there any defined order of the struct that is the response,
      and the other independent serializations within the body. Or
      alternatively can you rely on the first struct in the body being the
      request / response ?

      section 5, point 11, states
      Syntactically, an element may be "independent" or "embedded." An
      independent element is any element appearing at the top level of a
      serialization. All others are embedded elements.

      However its not clear exactly where the "top level of a serialization"
      is. [4]. The current implementations that i've looked at all have the
      independent elements within the body, after the request/response


      [1] http://groups.yahoo.com/group/soapbuilders/message/1450
      [2] http://groups.yahoo.com/group/soapbuilders/message/1831
      [3] http://groups.yahoo.com/group/soapbuilders/message/1861
      [4] http://groups.yahoo.com/group/soapbuilders/message/1473

      To unsubscribe from this group, send an email to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Henrik Frystyk Nielsen
      ... is ... Isn t it only when there is no true root of a serialization (for example multiple interlinked multi-refs) that the root attribute may have to be
      Message 62 of 62 , Apr 22, 2001
      • 0 Attachment
        Noah writes:
        >Henrik writes:
        >>> What I think needs clarification is in section 7.1 [2] where it
        >>> should say that the request as well as the response must be
        >>> serialized as the root object of the graph if encoded according to
        >>> section 5.
        >I agree. Would it make sense to go a bit further and establish rules
        >along the lines of:
        >* (Chap 5) If no multi-refs are referenced, use of the root attribute
        >optional. The lexical root of the tree is deemed a root of the object


        Isn't it only when there is no "true root" of a serialization (for
        example multiple interlinked multi-refs) that the root attribute may
        have to be used to disambiguate the true root of an object graph? Also,
        this might be special to object graphs as it wouldn't cause any problems
        for an RDF graph, for example.

        I agree that in the simple case of no multi-refs, the lexical root of
        the tree is the root of the object graph as well.

        >* (Chap 7) As you suggest: RPC request/response must be the root of
        >graph, and there can be only one root of the serialization (else fault)


        >* (Chap 5 or 7, I'm not sure) Either in all uses of the encoding (chap
        >or when used specifically for RPC (Chap 7 ...which would BTW apply to
        >other encodings too...a good thing I think) "When references to
        >objects are present an a serialization, the ROOT attribute must be used
        >establish the root of the object graph." A concern I have about this
        >that there might be problems when doing partial deserializations...you
        >might be deserializing a tree, for my header it might only be a subtree

        >(for graphs in which that makes sense), which one(s) need a ROOT

        If my statement above is true then it seems that this should be
        mentioned in section 7 as it implies object graphs. However, it seems
        that the MUST requirement for use of the "root" attribute only applies
        in the case of multiple, interlinked multi-refs. The graph may be
        unambiguous even with multi-refs involved which seems to call for a for
        a MAY in those cases, no?

        >What do you think?

      Your message has been successfully submitted and would be delivered to recipients shortly.