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

RE: [soapbuilders] multiple immediate children in doc/literal?

Expand Messages
  • Wes Moulder
    My guess would be either that, or decomposing it into two messages, a la boxcarring. Theoretically, it should match up against the message in the wsdl, and
    Message 1 of 22 , Jul 30, 2002
    • 0 Attachment

      My guess would be either that, or decomposing it into two messages, a la boxcarring.  Theoretically, it should match up against the message in the wsdl, and dispatch to the appropriate message that contains both parts though.

       

      --Wes

       

      -----Original Message-----
      From: Rich Salz [mailto:r.salz@...]
      Sent: Tuesday, July 30, 2002 12:27 PM
      To: Matt Long
      Cc: soapbuilders@yahoogroups.com
      Subject: Re: [soapbuilders] multiple immediate children in doc/literal?

       

      > I don't
      > believe that the namespace issue is an issue.

      I was too terse. I  meant how do the various SOAP stacks dispatch the
      message when top-level parts are in different namespaces?  Or do they
      just look at the first child and dispatch to its handler?
            /r$



      -----------------------------------------------------------------
      This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Bob Cunnings
      FWIW the toolkit here dispatches on the basis of the request URI, and the registered handler receives the entire contents of the body, which it may process as
      Message 2 of 22 , Jul 30, 2002
      • 0 Attachment
        FWIW the toolkit here dispatches on the basis of the request URI, and the
        registered handler receives the entire contents of the body, which it may
        process as it pleases. The quantity and namespaces of body children aren't
        relevant to the dispatch mechanism.

        RC

        > > I don't
        > > believe that the namespace issue is an issue.
        >
        > I was too terse. I meant how do the various SOAP stacks dispatch the
        > message when top-level parts are in different namespaces? Or do they
        > just look at the first child and dispatch to its handler?
        > /r$
        >
        >
      • Matt Long
        Hi Rich, Most use the first element name and/or + namespace much like what the tests where at Interop III F2F where configured to represent...of course I was
        Message 3 of 22 , Jul 30, 2002
        • 0 Attachment
          Hi Rich,

          Most use the first element name and/or + namespace much like what the
          tests where at Interop III F2F where configured to represent...of course
          I was having F2Tidy-Bowl man and was not able to address some of these
          issues on day 2.

          I suppose that method, i.e. first element, has been the natural
          progression especially since depreciation of SOAPAction in v1.2. The
          downside is that you cannot have a repeating first element name in the
          WSDL or import it. Some may use first element + namespace, some don't.

          Of course != SOAPAction across doc/lit messages also works, but it seems
          to be out-of-favor due to v1.2.


          Thx,

          -Matt Long
          Phalanx Systems, LLC



          > -----Original Message-----
          > From: Rich Salz [mailto:r.salz@...]
          > Sent: Tuesday, July 30, 2002 12:27 PM
          > To: Matt Long
          > Cc: soapbuilders@yahoogroups.com
          > Subject: Re: [soapbuilders] multiple immediate children in
          doc/literal?
          >
          > > I don't
          > > believe that the namespace issue is an issue.
          >
          > I was too terse. I meant how do the various SOAP stacks dispatch the
          > message when top-level parts are in different namespaces? Or do they
          > just look at the first child and dispatch to its handler?
          > /r$
          >
          >
          > ------------------------ Yahoo! Groups Sponsor
          >
          > -----------------------------------------------------------------
          > This group is a forum for builders of SOAP implementations to discuss
          > implementation and interoperability issues. Please stay on-topic.
          >
          > To unsubscribe from this group, send an email to:
          > soapbuilders-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
          >
        • Pete Hendry
          On the subject of using a validating parser, how can the parser know that the body should contain 2 elements, or what elements they should be? What I mean is
          Message 4 of 22 , Jul 30, 2002
          • 0 Attachment
            On the subject of using a validating parser, how can the parser know that the body should contain 2 elements, or what elements they should be? What I mean is you can use a validating parser to validate that *each* element is valid but the parser can't tell what elements were supposed to be in the message in the first place. I find this a flaw in SOAP where a message cannot be validated as the correct message using a validating parser. However, I can't see how you could define a generic content holder like Body and solve this problem. My only suggestion would be that the Body could be defined as a restriction of env:Body defined in your target schema and defining the exact content of the body. However, this would not be allowed by the spec and would complicate things somewhat (although I would love to be able to fire the message at a validating parser and know it was valid).

            Pete


            Matt Long wrote:
            Rich,

            I think it does make sense in the fact that two documents can be
            contained in the soap message and it is allowable under spec. I don't
            believe that the namespace issue is an issue. A validating parser (for
            literals) must understand all namespaces and their respective scopes.
            The prefixes are merely place holders for the resolving uri and must be
            resolved (validating parser or not).

            Thx,

            -Matt Long
            Phalanx Systems, LLC

            -----Original Message-----
            From: Rich Salz [mailto:r.salz@...]
            Sent: Tuesday, July 30, 2002 10:11 AM
            To: soapbuilders@yahoogroups.com
            Subject: [soapbuilders] multiple immediate children in doc/literal?

            Using doc/literal mode, does it make sense to have a soap message
            where
            the Body has more than one child node?
            <soap-env:envelope>
            <soap-env:body>
            <tns:foo>...</tns:foo>
            <tns:bar>...</tns:bar>
            </soap-env:body>
            </soap-env:envelope>

            My gut feeling is that (a) I'm not sure this makes sense; and (b) it
            will cause interop problems, esp if tns:bar becomes
            some-other-namespace:bar.

            Comments?
            /r$


            ------------------------ Yahoo! Groups Sponsor

            -----------------------------------------------------------------
            This group is a forum for builders of SOAP implementations to discuss
            implementation and interoperability issues. Please stay on-topic.

            To unsubscribe from this group, send an email to:
            soapbuilders-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/



            ------------------------ Yahoo! Groups Sponsor ---------------------~-->
            Free $5 Love Reading
            Risk Free!
            http://us.click.yahoo.com/NsdPZD/PfREAA/Ey.GAA/W6uqlB/TM
            ---------------------------------------------------------------------~->

            -----------------------------------------------------------------
            This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.

            To unsubscribe from this group, send an email to:
            soapbuilders-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



          • Matt Long
            Pete, If the message is literal (rpc | document), each message part can be validated against the schema in WSDL. Likewise, literal headers can be validated
            Message 5 of 22 , Jul 31, 2002
            • 0 Attachment

              Pete,

               

              If the message is literal (rpc | document), each message part can be validated against the schema in WSDL.  Likewise, literal headers can be validated also.

               

              ..how can the parser know that the body should contain 2 elements”

               

              The wsdl:message will contain 2 wsdl:parts, _each_ part (not element) is then validated independent of the other (just like a literal header).  The part can be validated against the schema (after a check of the required namespaces).

               

               

              Thx,

               

              -Matt Long

              Phalanx Systems, LLC

               

               

              -----Original Message-----
              From: Pete Hendry [mailto:peter.hendry@...]
              Sent: Wednesday, July 31, 2002 1:41 AM
              To: soapbuilders@yahoogroups.com
              Subject: Re: [soapbuilders] multiple immediate children in doc/literal?

               

              On the subject of using a validating parser, how can the parser know that the body should contain 2 elements, or what elements they should be? What I mean is you can use a validating parser to validate that *each* element is valid but the parser can't tell what elements were supposed to be in the message in the first place. I find this a flaw in SOAP where a message cannot be validated as the correct message using a validating parser. However, I can't see how you could define a generic content holder like Body and solve this problem. My only suggestion would be that the Body could be defined as a restriction of env:Body defined in your target schema and defining the exact content of the body. However, this would not be allowed by the spec and would complicate things somewhat (although I would love to be able to fire the message at a validating parser and know it was valid).

              Pete


              Matt Long wrote:

              Rich,

              I think it does make sense in the fact that two documents can be
              contained in the soap message and it is allowable under spec.  I don't
              believe that the namespace issue is an issue.  A validating parser (for
              literals) must understand all namespaces and their respective scopes.
              The prefixes are merely place holders for the resolving uri and must be
              resolved (validating parser or not).

              Thx,

              -Matt Long
              Phalanx Systems, LLC
              -----Original Message-----
              From: Rich Salz [mailto:r.salz@...]
              Sent: Tuesday, July 30, 2002 10:11 AM
              To: soapbuilders@yahoogroups.com
              Subject: [soapbuilders] multiple immediate children in doc/literal?

              Using doc/literal mode, does it make sense to have a soap message
              where
              the Body has more than one child node?
              <soap-env:envelope>
                <soap-env:body>
                  <tns:foo>...</tns:foo>
                  <tns:bar>...</tns:bar>
                </soap-env:body>
              </soap-env:envelope>

              My gut feeling is that (a) I'm not sure this makes sense; and (b) it
              will cause interop problems, esp if tns:bar becomes
              some-other-namespace:bar.

              Comments?
              /r$


              ------------------------ Yahoo! Groups Sponsor

              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss
              implementation and interoperability issues.  Please stay on-topic.

              To unsubscribe from this group, send an email to:
              soapbuilders-unsubscribe@yahoogroups.com



              Your use of Yahoo! Groups is subject to
              http://docs.yahoo.com/info/terms/



              ------------------------ Yahoo! Groups Sponsor ---------------------~-->
              Free $5 Love Reading
              Risk Free!
              http://us.click.yahoo.com/NsdPZD/PfREAA/Ey.GAA/W6uqlB/TM
              ---------------------------------------------------------------------~->

              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

              To unsubscribe from this group, send an email to:
              soapbuilders-unsubscribe@yahoogroups.com

               

              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

              To unsubscribe from this group, send an email to:
              soapbuilders-unsubscribe@yahoogroups.com



              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            • Pete Hendry
              That s my point. Each body element can be validated as the parser can lookup the element name in the schema. But, the parser can t know what elements are
              Message 6 of 22 , Jul 31, 2002
              • 0 Attachment
                That's my point. Each body element can be validated as the parser can lookup the element name in the schema. But, the parser can't know what elements are supposed to be in the body and whether the elements that are there are valid against any valid message format.

                Pete

                Matt Long wrote:

                Pete,

                 

                If the message is literal (rpc | document), each message part can be validated against the schema in WSDL.   Likewise, literal headers can be validated also.

                 

                .. how can the parser know that the body should contain 2 elements”

                 

                The wsdl:message will contain 2 wsdl:parts, _ each_ part (not element) is then validated independent of the other (just like a literal header).  The part can be validated against the schema (after a check of the required namespaces).

                 

                 

                Thx,

                 

                -Matt Long

                Phalanx Systems, LLC

                 

                 

                -----Original Message-----
                From: Pete Hendry [mailto:peter.hendry@...]
                Sent: Wednesday, July 31, 2002 1:41 AM
                To: soapbuilders@yahoogroups.com
                Subject: Re: [soapbuilders] multiple immediate children in doc/literal?

                 

                On the subject of using a validating parser, how can the parser know that the body should contain 2 elements, or what elements they should be? What I mean is you can use a validating parser to validate that *each* element is valid but the parser can't tell what elements were supposed to be in the message in the first place. I find this a flaw in SOAP where a message cannot be validated as the correct message using a validating parser. However, I can't see how you could define a generic content holder like Body and solve this problem. My only suggestion would be that the Body could be defined as a restriction of env:Body defined in your target schema and defining the exact content of the body. However, this would not be allowed by the spec and would complicate things somewhat (although I would love to be able to fire the message at a validating parser and know it was valid).

                Pete


                Matt Long wrote:

                Rich,



                I think it does make sense in the fact that two documents can be

                contained in the soap message and it is allowable under spec.  I don't

                believe that the namespace issue is an issue.  A validating parser (for

                literals) must understand all namespaces and their respective scopes.

                The prefixes are merely place holders for the resolving uri and must be

                resolved (validating parser or not).



                Thx,



                -Matt Long

                Phalanx Systems, LLC
                -----Original Message-----

                From: Rich Salz [mailto:r.salz@...]

                Sent: Tuesday, July 30, 2002 10:11 AM

                To: soapbuilders@yahoogroups.com

                Subject: [soapbuilders] multiple immediate children in doc/literal?



                Using doc/literal mode, does it make sense to have a soap message
                where
                the Body has more than one child node?

                <soap-env:envelope>

                  <soap-env:body>

                    <tns:foo>...</tns:foo>

                    <tns:bar>...</tns:bar>

                  </soap-env:body>

                </soap-env:envelope>



                My gut feeling is that (a) I'm not sure this makes sense; and (b) it

                will cause interop problems, esp if tns:bar becomes

                some-other-namespace:bar.



                Comments?

                /r$





                ------------------------ Yahoo! Groups Sponsor



                -----------------------------------------------------------------

                This group is a forum for builders of SOAP implementations to discuss

                implementation and interoperability issues.  Please stay on-topic.



                To unsubscribe from this group, send an email to:

                soapbuilders-unsubscribe@yahoogroups.com







                Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/






                ------------------------ Yahoo! Groups Sponsor ---------------------~-->

                Free $5 Love Reading

                Risk Free!

                http://us.click.yahoo.com/NsdPZD/PfREAA/Ey.GAA/W6uqlB/TM

                ---------------------------------------------------------------------~->



                -----------------------------------------------------------------

                This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.



                To unsubscribe from this group, send an email to:

                soapbuilders-unsubscribe@yahoogroups.com



                 



                Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






                -----------------------------------------------------------------
                This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                To unsubscribe from this group, send an email to:
                soapbuilders-unsubscribe@yahoogroups.com



                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .



                -----------------------------------------------------------------
                This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                To unsubscribe from this group, send an email to:
                soapbuilders-unsubscribe@yahoogroups.com



                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .

              • Rich Salz
                ... By validating I assume you mean XSD schema-valid, not basic XML valid. ... Can t you determine everything from the WSDL? /r$
                Message 7 of 22 , Jul 31, 2002
                • 0 Attachment
                  > On the subject of using a validating parser, how can the parser know
                  > that the body should contain 2 elements, or what elements they should
                  > be? What I mean is you can use a validating parser to validate that
                  > *each* element is valid but the parser can't tell what elements were
                  > supposed to be in the message in the first place.

                  By validating I assume you mean XSD schema-valid, not basic XML valid.

                  > I find this a flaw in
                  > SOAP where a message cannot be validated as the correct message using a
                  > validating parser.

                  Can't you determine everything from the WSDL?
                  /r$
                • Matt Long
                  Pete, I must be missing something. If the wsdl:message contains wsdl:part (s) then the message parts are known. If some of those wsdl:part are omitted, then
                  Message 8 of 22 , Jul 31, 2002
                  • 0 Attachment

                    Pete,

                     

                    I must be missing something.  If the wsdl:message contains wsdl:part (s) then the message parts are known.  If some of those wsdl:part are omitted, then the message is invalid.  What am I missing here?

                     

                    Thx,

                     

                    -Matt Long

                    Phalanx Systems, LLC

                     

                     

                    That's my point. Each body element can be validated as the parser can lookup the element name in the schema. But, the parser can't know what elements are supposed to be in the body and whether the elements that are there are valid against any valid message format.

                    Pete

                    Matt Long wrote:

                    Pete,

                     

                    If the message is literal (rpc | document), each message part can be validated against the schema in WSDL.   Likewise, literal headers can be validated also.

                     

                    “.. how can the parser know that the body should contain 2 elements”

                     

                    The wsdl:message will contain 2 wsdl:parts, _ each_ part (not element) is then validated independent of the other (just like a literal header).  The part can be validated against the schema (after a check of the required namespaces).

                     

                     

                    Thx,

                     

                    -Matt Long

                    Phalanx Systems, LLC

                     

                     

                    -----Original Message-----
                    From: Pete Hendry [mailto:peter.hendry@...]
                    Sent: Wednesday, July 31, 2002 1:41 AM
                    To: soapbuilders@yahoogroups.com
                    Subject: Re: [soapbuilders] multiple immediate children in doc/literal?

                     

                    On the subject of using a validating parser, how can the parser know that the body should contain 2 elements, or what elements they should be? What I mean is you can use a validating parser to validate that *each* element is valid but the parser can't tell what elements were supposed to be in the message in the first place. I find this a flaw in SOAP where a message cannot be validated as the correct message using a validating parser. However, I can't see how you could define a generic content holder like Body and solve this problem. My only suggestion would be that the Body could be defined as a restriction of env:Body defined in your target schema and defining the exact content of the body. However, this would not be allowed by the spec and would complicate things somewhat (although I would love to be able to fire the message at a validating parser and know it was valid).

                    Pete


                    Matt Long wrote:

                    Rich,



                    I think it does make sense in the fact that two documents can be

                    contained in the soap message and it is allowable under spec.  I don't

                    believe that the namespace issue is an issue.  A validating parser (for

                    literals) must understand all namespaces and their respective scopes.

                    The prefixes are merely place holders for the resolving uri and must be

                    resolved (validating parser or not).



                    Thx,



                    -Matt Long

                    Phalanx Systems, LLC
                    -----Original Message-----

                    From: Rich Salz [mailto:r.salz@...]

                    Sent: Tuesday, July 30, 2002 10:11 AM

                    To: soapbuilders@yahoogroups.com

                    Subject: [soapbuilders] multiple immediate children in doc/literal?



                    Using doc/literal mode, does it make sense to have a soap message
                    where
                    the Body has more than one child node?

                            <soap-env:envelope>

                              <soap-env:body>

                                <tns:foo>...</tns:foo>

                                <tns:bar>...</tns:bar>

                              </soap-env:body>

                            </soap-env:envelope>



                    My gut feeling is that (a) I'm not sure this makes sense; and (b) it

                    will cause interop problems, esp if tns:bar becomes

                    some-other-namespace:bar.



                    Comments?

                     /r$





                    ------------------------ Yahoo! Groups Sponsor



                    -----------------------------------------------------------------

                    This group is a forum for builders of SOAP implementations to discuss

                    implementation and interoperability issues.  Please stay on-topic.



                    To unsubscribe from this group, send an email to:

                    soapbuilders-unsubscribe@yahoogroups.com







                    Your use of Yahoo! Groups is subject to
                    http://docs.yahoo.com/info/terms/






                    ------------------------ Yahoo! Groups Sponsor ---------------------~-->

                    Free $5 Love Reading

                    Risk Free!

                    http://us.click.yahoo.com/NsdPZD/PfREAA/Ey.GAA/W6uqlB/TM

                    ---------------------------------------------------------------------~->



                    -----------------------------------------------------------------

                    This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.



                    To unsubscribe from this group, send an email to:

                    soapbuilders-unsubscribe@yahoogroups.com



                     




                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/





                    -----------------------------------------------------------------
                    This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                    To unsubscribe from this group, send an email to:
                    soapbuilders-unsubscribe@yahoogroups.com



                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .

                     



                    -----------------------------------------------------------------
                    This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                    To unsubscribe from this group, send an email to:
                    soapbuilders-unsubscribe@yahoogroups.com



                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .

                     

                  • Matt Long
                    Here is my spin. 1) The validating parser only validates a literal message part against the schema in WSDL. 2) The message is valid only is the wsdl:part (s)
                    Message 9 of 22 , Jul 31, 2002
                    • 0 Attachment
                      Here is my spin.

                      1) The validating parser only validates a literal message part against
                      the schema in WSDL.
                      2) The message is valid only is the wsdl:part (s) in Body are present.

                      If a message contains 'n' parts in Body, then each part must correspond
                      to a wsdl:part in then message, else invalid message. Each part in the
                      message can be validated against the schema in the WSDL.

                      Make sense?

                      Thx,

                      -Matt Long
                      Phalanx Systems, LLC



                      > -----Original Message-----
                      > From: Rich Salz [mailto:r.salz@...]
                      > Sent: Wednesday, July 31, 2002 9:10 AM
                      > To: Pete Hendry
                      > Cc: soapbuilders@yahoogroups.com
                      > Subject: Re: [soapbuilders] multiple immediate children in
                      doc/literal?
                      >
                      > > On the subject of using a validating parser, how can the parser know
                      > > that the body should contain 2 elements, or what elements they
                      should
                      > > be? What I mean is you can use a validating parser to validate that
                      > > *each* element is valid but the parser can't tell what elements were
                      > > supposed to be in the message in the first place.
                      >
                      > By validating I assume you mean XSD schema-valid, not basic XML valid.
                      >
                      > > I find this a flaw in
                      > > SOAP where a message cannot be validated as the correct message
                      using a
                      > > validating parser.
                      >
                      > Can't you determine everything from the WSDL?
                      > /r$
                      >
                      >
                      > ------------------------ Yahoo! Groups Sponsor
                      >
                      > -----------------------------------------------------------------
                      > This group is a forum for builders of SOAP implementations to discuss
                      > implementation and interoperability issues. Please stay on-topic.
                      >
                      > To unsubscribe from this group, send an email to:
                      > soapbuilders-unsubscribe@yahoogroups.com
                      >
                      >
                      >
                      > Your use of Yahoo! Groups is subject to
                      http://docs.yahoo.com/info/terms/
                      >
                    • Pete Hendry
                      ... Yes. ... You can by reading the WSDL and writing your own validation. However, I think if you are using a standard based on XML then a basic feature should
                      Message 10 of 22 , Jul 31, 2002
                      • 0 Attachment
                        Rich Salz wrote:

                        >By validating I assume you mean XSD schema-valid, not basic XML valid.
                        >

                        Yes.

                        >Can't you determine everything from the WSDL?
                        >

                        You can by reading the WSDL and writing your own validation. However, I
                        think if you are using a standard based on XML then a basic feature
                        should be that you can validate it using an out-of-the-box XML parser.
                        But an XML parser can't read WSDL. It can find the schema using XPath or
                        whatever (another thing about the way things are at the moment is that
                        the schemas are not tagged with for example an ID so they are easy to
                        reference for a parser) but there is other information in the WSDL they
                        would need to validate the message. I think this breaks with part of the
                        purpose of using XML in the first place - schema + validating parser.

                        Pete
                      • Rich Salz
                        You already need out of band information since PI s aren t legal in SOAP, so you need a way to link the schema to the message. Basically you re saying that XML
                        Message 11 of 22 , Jul 31, 2002
                        • 0 Attachment
                          You already need out of band information since PI's aren't legal in
                          SOAP, so you need a way to link the schema to the message.

                          Basically you're saying that XML Schema isn't rich enough to be able to
                          validate all SOAP messages.

                          I have no problem with that. :)
                          /r$
                        • noah_mendelsohn@us.ibm.com
                          FWIW, SOAP 1.2 clarifies the implications of multiple children of body [1]: An ultimate SOAP receiver MUST correctly process the immediate children of the
                          Message 12 of 22 , Jul 31, 2002
                          • 0 Attachment
                            FWIW, SOAP 1.2 clarifies the implications of multiple children of body
                            [1]:

                            "An ultimate SOAP receiver MUST correctly process the immediate children of
                            the SOAP body (see 5.3 SOAP Body). However, with the exception of SOAP
                            faults (see 5.4 SOAP Fault), Part 1 of this specification (this document)
                            mandates no particular structure or interpretation of these elements, and
                            provides no standard means for specifying the processing to be done."

                            Note it says children, not child. Note that it (intentionally) does not
                            say anything about the order in which processing occurs. Note that it
                            specifically declines to impose a "structure or interpretation" that's
                            standard across SOAP. So, in particular:

                            * Multiple elements may be need not represent multiple units of work
                            (boxcarring). Alternatively, one or another element could be data to be
                            used by the other(s)
                            * If they do represent multiple units of work, the order of processing is
                            not determined (unless some header targeted to the endpoint determines an
                            order)
                            * If there is a single unit of work + data, nothing says whether the
                            first, middle, or last is actually the operation to be performed.

                            In short: the ultimate receiver must understand the implications of all
                            the elements in the <body> taken together. How it understands that and
                            whether the model for one endpoint is the same or different as for others
                            is beyond the scope of the SOAP 1.2 specification. The pros and cons of
                            this choice were debated at great length. Note that it would be trivial
                            to build a header like:

                            <env:Soap>
                            <env:Header>
                            <someNs:boxcarBodies mustUnderstand="true">
                            <someNs:bodyProcessingOrder>
                            firstToLast
                            </someNs:bodyProcessingOrder>
                            </someNs:boxcarBodies mustUnderstand>
                            </env:Header>
                            <env:Body>
                            <n:b1>....</n:b1>
                            <n2:b2>....</n2:b2>
                            </env:Body>
                            </env:Soap>

                            Or some such. The point is: you make SOAP as generic as possible, and
                            use its own extension mechanisms to tailor it. If some of these headers
                            become so widely agreed-upon that they are nearly universally understood,
                            that's terrific. Of course, the specification for boxcarBodies must
                            describe the exact semantics impossed on the bodies, when to fault, etc.
                            Other conventions can be standardized using other headers.

                            Lacking such a header, if the endpoint sees a body that it is not
                            completely prepared to process (I.e. is confused about why there might be
                            multiple children), it MUST fault. It is NOT OK to just randomly process
                            them in order, or process the first one only, in some vague hope that it
                            might be the right thing to do. We're trying to make this all industrial
                            strength. The spec mandates that if you aren't truly sure what to do with
                            the body, you fault.

                            [1]
                            http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#structinterpbodies

                            ------------------------------------------------------------------
                            Noah Mendelsohn Voice: 1-617-693-4036
                            IBM Corporation Fax: 1-617-693-8676
                            One Rogers Street
                            Cambridge, MA 02142
                            ------------------------------------------------------------------
                          • Rosimildo daSIlva
                            ... I read this way: SOAP 1.2 is a beast with 100+ page spec, and the only thing it defines is two elements, Header and Body. The content of these
                            Message 13 of 22 , Jul 31, 2002
                            • 0 Attachment
                              --- noah_mendelsohn@... wrote:
                              > FWIW, SOAP 1.2 clarifies the implications of
                              > multiple children of body
                              > [1]:
                              >
                              > "An ultimate SOAP receiver MUST correctly process
                              > the immediate children of
                              > the SOAP body (see 5.3 SOAP Body). However, with the
                              > exception of SOAP
                              > faults (see 5.4 SOAP Fault), Part 1 of this
                              > specification (this document)
                              > mandates no particular structure or interpretation
                              > of these elements, and
                              > provides no standard means for specifying the
                              > processing to be done."
                              >
                              > Note it says children, not child. Note that it
                              > (intentionally) does not
                              > say anything about the order in which processing
                              > occurs. Note that it
                              > specifically declines to impose a "structure or
                              > interpretation" that's
                              > standard across SOAP.

                              <rant on>

                              I read this way:

                              SOAP 1.2 is a beast with 100+ page spec, and
                              the only thing it defines is two elements,
                              Header and Body. The content of these elements
                              are "vaguely" defined, and they can contain
                              just about anything that you can do with XML.

                              One could question: What is the value of SOAP
                              at all ? Why not just transport XML documents
                              over any prococol as SOAP does ?

                              After doing SOAP, along with your guys here,
                              I have this feeling that I understand it less
                              each day.

                              </rant on>











                              __________________________________________________
                              Do You Yahoo!?
                              Yahoo! Health - Feel better, live better
                              http://health.yahoo.com
                            • Rich Salz
                              SOAP 1.1 hit the 80/20 rule. SOAP 1.2 was taken over by comp sci theorists and unfortunately it s now 20/80. SOAP 1.1 could be tricky because big things
                              Message 14 of 22 , Jul 31, 2002
                              • 0 Attachment
                                SOAP 1.1 hit the 80/20 rule.
                                SOAP 1.2 was taken over by comp sci theorists and unfortunately it's now
                                20/80. SOAP 1.1 could be tricky because big things lurked in terse
                                corners of its language. SOAP 1.2 is tricky because you can't stay away
                                while reading it. Infoset allowing alternate serializations -- for a wire
                                protocol!? Bah.
                                /r$
                              • graham glass
                                hi rosimildo, if you think the SOAP 1.2 specification is large, you should check out the 500 page UDDI 3.0 specification! cheers, graham ... From: Rosimildo
                                Message 15 of 22 , Jul 31, 2002
                                • 0 Attachment
                                  hi rosimildo,
                                   
                                  if you think the SOAP 1.2 specification is large, you should check out
                                  the 500 page UDDI 3.0 specification!
                                   
                                  cheers,
                                  graham
                                  -----Original Message-----
                                  From: Rosimildo daSIlva [mailto:rosimildo@...]
                                  Sent: Wednesday, July 31, 2002 3:33 PM
                                  To: soapbuilders@yahoogroups.com
                                  Subject: Re: [soapbuilders] multiple immediate children in doc/literal?

                                  --- noah_mendelsohn@... wrote:
                                  > FWIW, SOAP 1.2 clarifies the implications of
                                  > multiple children of body
                                  > [1]:
                                  >
                                  > "An ultimate SOAP receiver MUST correctly process
                                  > the immediate children of
                                  > the SOAP body (see 5.3 SOAP Body). However, with the
                                  > exception of SOAP
                                  > faults (see 5.4 SOAP Fault), Part 1 of this
                                  > specification (this document)
                                  > mandates no particular structure or interpretation
                                  > of these elements, and
                                  > provides no standard means for specifying the
                                  > processing to be done."
                                  >
                                  > Note it says children, not child.  Note that it
                                  > (intentionally) does not
                                  > say anything about the order in which processing
                                  > occurs.  Note that it
                                  > specifically declines to impose a "structure or
                                  > interpretation" that's
                                  > standard across SOAP.

                                  <rant on>

                                  I read this way:

                                  SOAP 1.2 is a beast with 100+ page spec, and
                                  the only thing it defines is two elements,
                                  Header and Body. The content of these elements
                                  are "vaguely" defined, and they can contain
                                  just about anything that you can do with XML.

                                  One could question: What is the value of SOAP
                                  at all ? Why not just transport XML documents
                                  over any prococol as SOAP does ?

                                  After doing SOAP, along with your guys here,
                                  I have this feeling that I understand it less
                                  each day.

                                  </rant on>











                                  __________________________________________________
                                  Do You Yahoo!?
                                  Yahoo! Health - Feel better, live better
                                  http://health.yahoo.com


                                  -----------------------------------------------------------------
                                  This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

                                  To unsubscribe from this group, send an email to:
                                  soapbuilders-unsubscribe@yahoogroups.com



                                  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                • Rosimildo daSIlva
                                  ... Outch ! That hurts. Sorry everybody, for my fustrastion. It has been a long day ! Rosimildo. __________________________________________________ Do You
                                  Message 16 of 22 , Jul 31, 2002
                                  • 0 Attachment
                                    --- graham glass <graham@...> wrote:
                                    > hi rosimildo,
                                    >
                                    > if you think the SOAP 1.2 specification is large,
                                    > you should check out
                                    > the 500 page UDDI 3.0 specification!
                                    >

                                    Outch ! That hurts.

                                    Sorry everybody, for my fustrastion. It has been
                                    a long day !

                                    Rosimildo.

                                    __________________________________________________
                                    Do You Yahoo!?
                                    Yahoo! Health - Feel better, live better
                                    http://health.yahoo.com
                                  • Matt Long
                                    ... I have to disagree with you both; you re both right! Thx, -Matt Long Phalanx Systems, LLC
                                    Message 17 of 22 , Aug 3, 2002
                                    • 0 Attachment
                                      Robert van Engelen wrote:

                                      > I disagree with Rich' opinion that comp. sci. theorists are to blame
                                      > (no offense, Rich ;-) ). I suspect that too many parties attempt to be
                                      > stakeholders in SOAP 1.2 to tweak it to be as widely applicable as
                                      > possible in order to claim IP rights for anything that uses XML over
                                      > HTTP/SMTP/TCP (I am not even sure anymore whether SOAP 1.2. requires
                                      > XML at all which used to be main advantage that SOAP had over other
                                      > protocols by utilizing XML as the lingua franca for RPC).

                                      I have to disagree with you both; you're both right!


                                      Thx,

                                      -Matt Long
                                      Phalanx Systems, LLC
                                    • Robert van Engelen
                                      ... Here is my two cents worth of unsollicited opinion (read: rant). It is certainly ironic that the bloat has crept into protocols such as UDDI 3.0 and SOAP
                                      Message 18 of 22 , Aug 3, 2002
                                      • 0 Attachment
                                        graham glass wrote:
                                        >
                                        > hi rosimildo,
                                        >
                                        > if you think the SOAP 1.2 specification is large, you should check out
                                        > the 500 page UDDI 3.0 specification!

                                        Here is my two cents worth of unsollicited opinion (read: rant).

                                        It is certainly ironic that the bloat has crept into protocols such
                                        as UDDI 3.0 and SOAP 1.2, while the original goal of these protocols
                                        was "lightweight" RPC and/or message exchange with lookup/discovery.

                                        On the one hand the usage context of SOAP 1.2 is greatly enlarged,
                                        while on the other hand SOAP 1.2 RPC's Section 5 encoding has been
                                        simplified in such a way that it breaks compatibility with SOAP 1.1 RPC
                                        encoding. I get the feeling that RPC encoding will be on its way out.
                                        As a result, SOAP's usefulness for language/platform interoperability
                                        will be diminished.

                                        Certainly, SOAP 1.1 promised to be a viable alternative to ORB systems
                                        because of its lightweight properties that allowed small-scale systems
                                        such as cellphones and embedded systems to use it rather than existing
                                        heavyweight ORB architectures. I am not sure if SOAP 1.2 will be able
                                        to fulfill this promise.

                                        I disagree with Rich' opinion that comp. sci. theorists are to blame
                                        (no offense, Rich ;-) ). I suspect that too many parties attempt to be
                                        stakeholders in SOAP 1.2 to tweak it to be as widely applicable as
                                        possible in order to claim IP rights for anything that uses XML over
                                        HTTP/SMTP/TCP (I am not even sure anymore whether SOAP 1.2. requires
                                        XML at all which used to be main advantage that SOAP had over other
                                        protocols by utilizing XML as the lingua franca for RPC).

                                        - Robert van Engelen, Computer Science Dept., FSU.
                                      • Rich Salz
                                        ... Hey, did you see that UDDI just turned spec development over to OASIS? That s interesting.
                                        Message 19 of 22 , Aug 6, 2002
                                        • 0 Attachment
                                          > It is certainly ironic that the bloat has crept into protocols such
                                          > as UDDI 3.0 and SOAP 1.2, while the original goal of these protocols
                                          > was "lightweight" RPC and/or message exchange with lookup/discovery.

                                          Hey, did you see that UDDI just turned spec development over to OASIS?

                                          That's interesting.
                                        Your message has been successfully submitted and would be delivered to recipients shortly.