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

Re: [soapbuilders] Null values.

Expand Messages
  • Simon Fell
    I m in no way suggesting that this a good thing. Just that looking through the spec, i see nothing that makes this invalid. (ignoring the namespaces)
    Message 1 of 62 , Apr 13, 2001
    • 0 Attachment
      I'm in no way suggesting that this a good thing. Just that looking
      through the spec, i see nothing that makes this invalid. (ignoring the
      namespaces)

      <Envelope>
      <Body>
      <Array id="foo" arrayType="xsd:string[1]">
      <item>bar</item>
      </Array>
      <echoStringArrayResponse>
      <outputStrings href="#foo" />
      </echoStringArrayResponse>
      </Body>
      </Envelope>

      _Please_ someone conclusively prove me wrong !

      Cheers
      Simon

      On Fri, 13 Apr 2001 14:02:42 -0500, in soap you wrote:

      >Simon Fell wrote:
      >>
      >> not at all, all it means is that the soap engine itself cannot work
      >> out the name of the request / response element itself. It can be told
      >> what it is without resorting to WSDL.
      >
      >so than the client needs to process WSDL to be able to interpret response
      >or use some other proprietary endpoint description - why it should do it -
      >what would be the motivation to do it?
      >
      >thanks,
      >
      >alek
    • 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
        is
        >optional. The lexical root of the tree is deemed a root of the object

        >graph.

        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
        the
        >graph, and there can be only one root of the serialization (else fault)

        yup

        >* (Chap 5 or 7, I'm not sure) Either in all uses of the encoding (chap
        5)
        >or when used specifically for RPC (Chap 7 ...which would BTW apply to
        >other encodings too...a good thing I think) "When references to
        multi-ref
        >objects are present an a serialization, the ROOT attribute must be used
        to
        >establish the root of the object graph." A concern I have about this
        is
        >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
        >attribute?

        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?

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