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

Userland SOAP Validator

Expand Messages
  • Simon Fell
    Wooo Hooo, i got 4s4c to pass the validator :) Quite an interesting exercise, it forced me to a) add support for arrays of xsd:ur-type (each item can be a
    Message 1 of 11 , Feb 7, 2001
    • 0 Attachment
      Wooo Hooo, i got 4s4c to pass the validator :)

      Quite an interesting exercise, it forced me to
      a) add support for arrays of xsd:ur-type (each item can be a different
      type)
      b) fix my broken TZ correction code in xsd:timeInstant support (not
      sure how i didn't spot this before)

      So, this was a against a private version of 4s4c (1.31), I'll
      hopefully be releasing it at the end of the week.

      Dave, i noticed on the timeInstant check (in manyTypesTest), that when
      you return the wrong timeInstant, the value that the error message
      says it was expecting is wrong.

      I was surprised by some of the constructs, particular the calendar
      one, i would of expected this to use arrays, rather than nested
      structs. There really should be a test for handling arrays of structs.

      Cheers
      Simon
      www.pocketsoap.com
    • Simon Fell
      [I m sending this again as PacBell appear to be randomly loosing email] Wooo Hooo, i got 4s4c to pass the validator :) Quite an interesting exercise, it forced
      Message 2 of 11 , Feb 8, 2001
      • 0 Attachment
        [I'm sending this again as PacBell appear to be randomly loosing
        email]


        Wooo Hooo, i got 4s4c to pass the validator :)

        Quite an interesting exercise, it forced me to
        a) add support for arrays of xsd:ur-type (each item can be a different
        type)
        b) fix my broken TZ correction code in xsd:timeInstant support (not
        sure how i didn't spot this before)

        So, this was a against a private version of 4s4c (1.31), I'll
        hopefully be releasing it at the end of the week.

        Dave, i noticed on the timeInstant check (in manyTypesTest), that when
        you return the wrong timeInstant, the value that the error message
        says it was expecting is wrong.

        I was surprised by some of the constructs, particular the calendar
        one, i would of expected this to use arrays, rather than nested
        structs. There really should be a test for handling arrays of structs.

        Cheers
        Simon
        www.pocketsoap.com
      • Dave Winer
        Hi Simon! I agree about using arrays. That s why I put the disclaimer on the page. We re still finding and fixing bugs in our SOAP 1.1 implementation. It s
        Message 3 of 11 , Feb 8, 2001
        • 0 Attachment
          Hi Simon!

          I agree about using arrays. That's why I put the disclaimer on the page.

          We're still finding and fixing bugs in our SOAP 1.1 implementation.

          "It's even worse than it appears."

          Dave


          ----- Original Message -----
          From: "Simon Fell" <soap@...>
          To: <soapbuilders@yahoogroups.com>
          Sent: Thursday, February 08, 2001 8:10 AM
          Subject: [soapbuilders] Userland SOAP Validator


          > [I'm sending this again as PacBell appear to be randomly loosing
          > email]
          >
          >
          > Wooo Hooo, i got 4s4c to pass the validator :)
          >
          > Quite an interesting exercise, it forced me to
          > a) add support for arrays of xsd:ur-type (each item can be a different
          > type)
          > b) fix my broken TZ correction code in xsd:timeInstant support (not
          > sure how i didn't spot this before)
          >
          > So, this was a against a private version of 4s4c (1.31), I'll
          > hopefully be releasing it at the end of the week.
          >
          > Dave, i noticed on the timeInstant check (in manyTypesTest), that when
          > you return the wrong timeInstant, the value that the error message
          > says it was expecting is wrong.
          >
          > I was surprised by some of the constructs, particular the calendar
          > one, i would of expected this to use arrays, rather than nested
          > structs. There really should be a test for handling arrays of structs.
          >
          > Cheers
          > Simon
          > www.pocketsoap.com
          >
          >
          > To unsubscribe from this group, send an email to:
          > soapbuilders-unsubscribe@yahoogroups.com
          >
          >
          >
          >
        • Glen Daniels
          A quick note for interop purposes with other Schema-aware systems. ur-type is no longer the name for the any type in Schema. The 10/24/2000 Schema release
          Message 4 of 11 , Feb 8, 2001
          • 0 Attachment
            A quick note for interop purposes with other Schema-aware systems.

            "ur-type" is no longer the name for the "any" type in Schema. The
            10/24/2000 Schema release (see [1])replaced it with "anyType".

            We should be retooling our implementations to support this change.

            [1] http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#Type_Derivation

            --Glen

            > -----Original Message-----
            > From: Simon Fell [mailto:soap@...]
            > Sent: Thursday, February 08, 2001 11:10 AM
            > To: soapbuilders@yahoogroups.com
            > Subject: [soapbuilders] Userland SOAP Validator
            >
            >
            > [I'm sending this again as PacBell appear to be randomly loosing
            > email]
            >
            >
            > Wooo Hooo, i got 4s4c to pass the validator :)
            >
            > Quite an interesting exercise, it forced me to
            > a) add support for arrays of xsd:ur-type (each item can be a different
            > type)
            > b) fix my broken TZ correction code in xsd:timeInstant support (not
            > sure how i didn't spot this before)
            >
            > So, this was a against a private version of 4s4c (1.31), I'll
            > hopefully be releasing it at the end of the week.
            >
            > Dave, i noticed on the timeInstant check (in manyTypesTest), that when
            > you return the wrong timeInstant, the value that the error message
            > says it was expecting is wrong.
            >
            > I was surprised by some of the constructs, particular the calendar
            > one, i would of expected this to use arrays, rather than nested
            > structs. There really should be a test for handling arrays of structs.
            >
            > Cheers
            > Simon
            > www.pocketsoap.com
            >
            > ------------------------ Yahoo! Groups Sponsor
            > ---------------------~-~>
            > eGroups is now Yahoo! Groups
            > Click here for more details
            > http://click.egroups.com/1/11231/0/_/_/_/981648712/
            > --------------------------------------------------------------
            > -------_->
            >
            > To unsubscribe from this group, send an email to:
            > soapbuilders-unsubscribe@yahoogroups.com
            >
            >
            >
          • Simon Fell
            However all SOAP (ignoring what s happening with WSDL for now) implementations are using the 1999 version of XSD, so this shouldn t be a problem. This does
            Message 5 of 11 , Feb 8, 2001
            • 0 Attachment
              However all SOAP (ignoring what's happening with WSDL for now)
              implementations are using the 1999 version of XSD, so this shouldn't
              be a problem.

              This does however highlight a problem i've raised before, as the
              schema specs continue to evolve, how does this effect SOAP and WSDL,
              there's no built in mechanism for a client to request that the server
              use a particular schema version. Which seems to push us to a receiver
              makes right model, probably migrating schema info using XSLT.

              Cheers
              Simon


              On Thu, 8 Feb 2001 11:41:45 -0500 , in soap you wrote:

              >
              >A quick note for interop purposes with other Schema-aware systems.
              >
              >"ur-type" is no longer the name for the "any" type in Schema. The
              >10/24/2000 Schema release (see [1])replaced it with "anyType".
              >
              >We should be retooling our implementations to support this change.
              >
              >[1] http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#Type_Derivation
              >
              >--Glen
              >
              >> -----Original Message-----
              >> From: Simon Fell [mailto:soap@...]
              >> Sent: Thursday, February 08, 2001 11:10 AM
              >> To: soapbuilders@yahoogroups.com
              >> Subject: [soapbuilders] Userland SOAP Validator
              >>
              >>
              >> [I'm sending this again as PacBell appear to be randomly loosing
              >> email]
              >>
              >>
              >> Wooo Hooo, i got 4s4c to pass the validator :)
              >>
              >> Quite an interesting exercise, it forced me to
              >> a) add support for arrays of xsd:ur-type (each item can be a different
              >> type)
              >> b) fix my broken TZ correction code in xsd:timeInstant support (not
              >> sure how i didn't spot this before)
              >>
              >> So, this was a against a private version of 4s4c (1.31), I'll
              >> hopefully be releasing it at the end of the week.
              >>
              >> Dave, i noticed on the timeInstant check (in manyTypesTest), that when
              >> you return the wrong timeInstant, the value that the error message
              >> says it was expecting is wrong.
              >>
              >> I was surprised by some of the constructs, particular the calendar
              >> one, i would of expected this to use arrays, rather than nested
              >> structs. There really should be a test for handling arrays of structs.
              >>
              >> Cheers
              >> Simon
              >> www.pocketsoap.com
              >>
              >> ------------------------ Yahoo! Groups Sponsor
              >> ---------------------~-~>
              >> eGroups is now Yahoo! Groups
              >> Click here for more details
              >> http://click.egroups.com/1/11231/0/_/_/_/981648712/
              >> --------------------------------------------------------------
              >> -------_->
              >>
              >> To unsubscribe from this group, send an email to:
              >> soapbuilders-unsubscribe@yahoogroups.com
              >>
              >>
              >>
              >
              >
              >To unsubscribe from this group, send an email to:
              >soapbuilders-unsubscribe@yahoogroups.com
              >
              >
            • Paul Kulchenko
              Hi, Simon! Right, however it brings the implementation question. I can accept both ur-type and AnyType, but can generate only one, so as soon as I (or anyone
              Message 6 of 11 , Feb 8, 2001
              • 0 Attachment
                Hi, Simon!

                Right, however it brings the implementation question. I can accept
                both ur-type and AnyType, but can generate only one, so as soon as I
                (or anyone else) start to do it on server side it immediately becomes
                non-interoperable with other client-side toolkits. To avoid this
                situation, we need to introduce understanding of both schemas on
                client side (more presicely on deserializer side) as soon as possible
                and after some time make changes in Serializer part. Otherwise we'll
                have hard time when one or another toolkit interoperability will be
                broken. Fortunately (?) not all toolkits have support for Arrays with
                complex types, so when they implement it, it can be done according to
                new version of specs.

                And you're absolutely right that we need to have some mechanism that
                let us avoid such situations.

                Best wishes, Paul.

                --- Simon Fell <soap@...> wrote:
                > However all SOAP (ignoring what's happening with WSDL for now)
                > implementations are using the 1999 version of XSD, so this
                > shouldn't
                > be a problem.
                >
                > This does however highlight a problem i've raised before, as the
                > schema specs continue to evolve, how does this effect SOAP and
                > WSDL,
                > there's no built in mechanism for a client to request that the
                > server
                > use a particular schema version. Which seems to push us to a
                > receiver
                > makes right model, probably migrating schema info using XSLT.
                >
                > Cheers
                > Simon
                >
                >
                > On Thu, 8 Feb 2001 11:41:45 -0500 , in soap you wrote:
                >
                > >
                > >A quick note for interop purposes with other Schema-aware systems.
                > >
                > >"ur-type" is no longer the name for the "any" type in Schema. The
                > >10/24/2000 Schema release (see [1])replaced it with "anyType".
                > >
                > >We should be retooling our implementations to support this change.
                > >
                > >[1]
                > http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#Type_Derivation
                > >
                > >--Glen
                > >
                > >> -----Original Message-----
                > >> From: Simon Fell [mailto:soap@...]
                > >> Sent: Thursday, February 08, 2001 11:10 AM
                > >> To: soapbuilders@yahoogroups.com
                > >> Subject: [soapbuilders] Userland SOAP Validator
                > >>
                > >>
                > >> [I'm sending this again as PacBell appear to be randomly loosing
                > >> email]
                > >>
                > >>
                > >> Wooo Hooo, i got 4s4c to pass the validator :)
                > >>
                > >> Quite an interesting exercise, it forced me to
                > >> a) add support for arrays of xsd:ur-type (each item can be a
                > different
                > >> type)
                > >> b) fix my broken TZ correction code in xsd:timeInstant support
                > (not
                > >> sure how i didn't spot this before)
                > >>
                > >> So, this was a against a private version of 4s4c (1.31), I'll
                > >> hopefully be releasing it at the end of the week.
                > >>
                > >> Dave, i noticed on the timeInstant check (in manyTypesTest),
                > that when
                > >> you return the wrong timeInstant, the value that the error
                > message
                > >> says it was expecting is wrong.
                > >>
                > >> I was surprised by some of the constructs, particular the
                > calendar
                > >> one, i would of expected this to use arrays, rather than nested
                > >> structs. There really should be a test for handling arrays of
                > structs.
                > >>
                > >> Cheers
                > >> Simon
                > >> www.pocketsoap.com
                > >>
                > >> ------------------------ Yahoo! Groups Sponsor
                > >> ---------------------~-~>
                > >> eGroups is now Yahoo! Groups
                > >> Click here for more details
                > >> http://click.egroups.com/1/11231/0/_/_/_/981648712/
                > >> --------------------------------------------------------------
                > >> -------_->
                > >>
                > >> To unsubscribe from this group, send an email to:
                > >> soapbuilders-unsubscribe@yahoogroups.com
                > >>
                > >>
                > >>
                > >
                > >
                > >To unsubscribe from this group, send an email to:
                > >soapbuilders-unsubscribe@yahoogroups.com
                > >
                > >
                >
                >
                > ------------------------ Yahoo! Groups Sponsor
                >
                > To unsubscribe from this group, send an email to:
                > soapbuilders-unsubscribe@yahoogroups.com
                >
                >


                __________________________________________________
                Do You Yahoo!?
                Get personalized email addresses from Yahoo! Mail - only $35
                a year! http://personal.mail.yahoo.com/
              • Paul Kulchenko
                Hi, All! I d like to talk about error codes from HTTP SOAP servers. As far as I remember 4 situation is possible. There is no questions about first two. There
                Message 7 of 11 , Feb 8, 2001
                • 0 Attachment
                  Hi, All!

                  I'd like to talk about error codes from HTTP SOAP servers.

                  As far as I remember 4 situation is possible. There is no questions
                  about first two. There were several long discussions about what
                  return with SOAP Fault, 200 or 500 and as I remember consensus was
                  for 200OK, but most toolkits return 500 or even 400? from Xmethods
                  (Tony, is it ApacheSOAP or XMethod's router?).

                  1. 200 OK + SOAP message (normal result)
                  2. 500 Server Error + error message (not SOAP)
                  3a. 500 Server Error + SOAP message (Fault result)
                  3b. 400 Bad Method + SOAP message (Fault result)
                  4. 200 OK + SOAP message (Fault result)

                  So, what's your take on it and should we stay we 200OK or will return
                  500 on SOAP Fault? Do we need to accept 400 or it's something that
                  could be changed on server side?

                  Best wishes, Paul.

                  __________________________________________________
                  Do You Yahoo!?
                  Get personalized email addresses from Yahoo! Mail - only $35
                  a year! http://personal.mail.yahoo.com/
                • Bob Cunnings
                  Hello, The SOAP 1.1 spec (section 6.2) was quite clear on this: HTTP status 500 must be returned when a SOAP fault has occurred:
                  Message 8 of 11 , Feb 8, 2001
                  • 0 Attachment
                    Hello,

                    The SOAP 1.1 spec (section 6.2) was quite clear on this: HTTP
                    status 500 must be returned when a SOAP fault has occurred:

                    http://www.w3.org/TR/SOAP/#_Toc478383529

                    The implementations here act per example 3a below.
                    3b and 4 would violate section 6.2. That doesn't mean, of course,
                    that this binding rule was a good idea to start with... it has certainly
                    been controversial enough.

                    RC

                    > Hi, All!
                    >
                    > I'd like to talk about error codes from HTTP SOAP servers.
                    >
                    > As far as I remember 4 situation is possible. There is no questions
                    > about first two. There were several long discussions about what
                    > return with SOAP Fault, 200 or 500 and as I remember consensus was
                    > for 200OK, but most toolkits return 500 or even 400? from Xmethods
                    > (Tony, is it ApacheSOAP or XMethod's router?).
                    >
                    > 1. 200 OK + SOAP message (normal result)
                    > 2. 500 Server Error + error message (not SOAP)
                    > 3a. 500 Server Error + SOAP message (Fault result)
                    > 3b. 400 Bad Method + SOAP message (Fault result)
                    > 4. 200 OK + SOAP message (Fault result)
                    >
                    > So, what's your take on it and should we stay we 200OK or will return
                    > 500 on SOAP Fault? Do we need to accept 400 or it's something that
                    > could be changed on server side?
                    >
                    > Best wishes, Paul.
                    >
                    > __________________________________________________
                    > Do You Yahoo!?
                    > Get personalized email addresses from Yahoo! Mail - only $35
                    > a year! http://personal.mail.yahoo.com/
                    >
                    >
                    > To unsubscribe from this group, send an email to:
                    > soapbuilders-unsubscribe@yahoogroups.com
                    >
                    >
                  • paulclinger@yahoo.com
                    Hi, Simon! Wooo Hooo (echo :)). I got SOAP::Lite to pass the validator :). Right, interesting exercise, and will work on standard SOAP::Lite, though small
                    Message 9 of 11 , Feb 8, 2001
                    • 0 Attachment
                      Hi, Simon!

                      Wooo Hooo (echo :)). I got SOAP::Lite to pass the validator :).

                      Right, interesting exercise, and will work on standard SOAP::Lite,
                      though small trick was used on server side. Since SOAP::Lite does
                      nothing special with timeInstant I just echoed it back, preservind
                      type and name of element. That's it. Also could be interesting to see
                      server side code for different implementations. Hopefully will be
                      included in next version.

                      As I understand next step is stress testing on SOAP servers :))

                      Best wishes, Paul.

                      --- In soapbuilders@y..., Simon Fell <soap@z...> wrote:
                      > [I'm sending this again as PacBell appear to be randomly loosing
                      > email]
                      >
                      >
                      > Wooo Hooo, i got 4s4c to pass the validator :)
                      >
                      > Quite an interesting exercise, it forced me to
                      > a) add support for arrays of xsd:ur-type (each item can be a
                      different
                      > type)
                      > b) fix my broken TZ correction code in xsd:timeInstant support (not
                      > sure how i didn't spot this before)
                      >
                      > So, this was a against a private version of 4s4c (1.31), I'll
                      > hopefully be releasing it at the end of the week.
                      >
                      > Dave, i noticed on the timeInstant check (in manyTypesTest), that
                      when
                      > you return the wrong timeInstant, the value that the error message
                      > says it was expecting is wrong.
                      >
                      > I was surprised by some of the constructs, particular the calendar
                      > one, i would of expected this to use arrays, rather than nested
                      > structs. There really should be a test for handling arrays of
                      structs.
                      >
                      > Cheers
                      > Simon
                      > www.pocketsoap.com
                    • Dave Winer
                      This is so cooool! What kind of stress testing do you want to do? Dave ... From: To: Sent: Thursday,
                      Message 10 of 11 , Feb 8, 2001
                      • 0 Attachment
                        This is so cooool!

                        What kind of stress testing do you want to do?

                        Dave


                        ----- Original Message -----
                        From: <paulclinger@...>
                        To: <soapbuilders@yahoogroups.com>
                        Sent: Thursday, February 08, 2001 3:10 PM
                        Subject: [soapbuilders] Re: Userland SOAP Validator


                        > Hi, Simon!
                        >
                        > Wooo Hooo (echo :)). I got SOAP::Lite to pass the validator :).
                        >
                        > Right, interesting exercise, and will work on standard SOAP::Lite,
                        > though small trick was used on server side. Since SOAP::Lite does
                        > nothing special with timeInstant I just echoed it back, preservind
                        > type and name of element. That's it. Also could be interesting to see
                        > server side code for different implementations. Hopefully will be
                        > included in next version.
                        >
                        > As I understand next step is stress testing on SOAP servers :))
                        >
                        > Best wishes, Paul.
                        >
                        > --- In soapbuilders@y..., Simon Fell <soap@z...> wrote:
                        > > [I'm sending this again as PacBell appear to be randomly loosing
                        > > email]
                        > >
                        > >
                        > > Wooo Hooo, i got 4s4c to pass the validator :)
                        > >
                        > > Quite an interesting exercise, it forced me to
                        > > a) add support for arrays of xsd:ur-type (each item can be a
                        > different
                        > > type)
                        > > b) fix my broken TZ correction code in xsd:timeInstant support (not
                        > > sure how i didn't spot this before)
                        > >
                        > > So, this was a against a private version of 4s4c (1.31), I'll
                        > > hopefully be releasing it at the end of the week.
                        > >
                        > > Dave, i noticed on the timeInstant check (in manyTypesTest), that
                        > when
                        > > you return the wrong timeInstant, the value that the error message
                        > > says it was expecting is wrong.
                        > >
                        > > I was surprised by some of the constructs, particular the calendar
                        > > one, i would of expected this to use arrays, rather than nested
                        > > structs. There really should be a test for handling arrays of
                        > structs.
                        > >
                        > > Cheers
                        > > Simon
                        > > www.pocketsoap.com
                        >
                        >
                        >
                        > To unsubscribe from this group, send an email to:
                        > soapbuilders-unsubscribe@yahoogroups.com
                        >
                        >
                        >
                      • David Crowley
                        There is also a fifth situation. 400 Bad Method + error message (not SOAP). The only way you can be reasonably sure that a SOAP message is being returned is
                        Message 11 of 11 , Feb 8, 2001
                        • 0 Attachment
                          There is also a fifth situation. 400 Bad Method + error message (not
                          SOAP). The only way you can be reasonably sure that a SOAP message is
                          being returned is if the result code is 200. IMHO the problem here is that
                          a SOAP errors should not show up as a transport error. SOAP has it's way
                          of dealing with errors using SOAPFault. HTTP has it's way of dealing with
                          errors with the server return codes. And the two shouldn't be
                          mixed. Because when you do, you end up in the strange situation you have
                          now where if you get back a 500 code, sometimes you can parse the response
                          and other times you can't. So SOAP has to know about the transport and the
                          transport has to know about SOAP. I'm sure there was good reasoning behind
                          the spec saying that 500 should be returned. Maybe someone has some
                          insight there?

                          David


                          At 09:33 AM 2/8/2001 -0800, you wrote:
                          >Hi, All!
                          >
                          >I'd like to talk about error codes from HTTP SOAP servers.
                          >
                          >As far as I remember 4 situation is possible. There is no questions
                          >about first two. There were several long discussions about what
                          >return with SOAP Fault, 200 or 500 and as I remember consensus was
                          >for 200OK, but most toolkits return 500 or even 400? from Xmethods
                          >(Tony, is it ApacheSOAP or XMethod's router?).
                          >
                          > 1. 200 OK + SOAP message (normal result)
                          > 2. 500 Server Error + error message (not SOAP)
                          > 3a. 500 Server Error + SOAP message (Fault result)
                          > 3b. 400 Bad Method + SOAP message (Fault result)
                          > 4. 200 OK + SOAP message (Fault result)
                          >
                          >So, what's your take on it and should we stay we 200OK or will return
                          >500 on SOAP Fault? Do we need to accept 400 or it's something that
                          >could be changed on server side?
                          >
                          >Best wishes, Paul.
                        Your message has been successfully submitted and would be delivered to recipients shortly.