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

Re-engaging

Expand Messages
  • Glen Daniels
    Well hot damn. Not only did I have a fabulous vacation, but I sync my mail to find upteen-hundred messages from all of you working together to try and get
    Message 1 of 13 , Apr 1, 2001
    • 0 Attachment
      Well hot damn.

      Not only did I have a fabulous vacation, but I sync my mail to find
      upteen-hundred messages from all of you working together to try and get
      basic
      interoperability going. Yay, soapbuilders! :) So, I'm currently (~6PM
      Pacific time) on the plane
      on the way home, and I'll summarize my reactions to what I've gathered of
      the
      recent activity here. Apologies if any of this is redundant, I synced very
      early this morning.

      First, to Dave and Jake - I'm really glad you guys have gotten involved in
      this
      effort after the initial somewhat confusing start.

      Now that I'll be back, I have to place 1st priority on Macromedia issues
      (and Axis development), but in my time around that I am still committed to
      this effort, and will try to work on getting an Apache-SOAP endpoint up
      ASAP.

      Re: null params in the BDG - I haven't seen the latest version, just the
      mails,
      so I just want to make sure it's clear in the text that the "nil" element
      name
      is not required - i.e <thisParam xsi:null="1"/> is just as good. A nit, to
      be
      sure, but I've seen this sort of thing confuse people before.

      Re: schema URIs - this is a rough one. The way we've started to deal with
      this in
      Apache SOAP is to follow the "be liberal in what you receive" maxim. We
      have an
      abstraction for the schema types, and we'll accept whatever you throw at us
      as
      long as it's consistent (i.e. 1999 schema uses "ur-type", 2000 uses
      "anyType",
      etc). We'll send whatever you set the "current schema" setting to. I think
      this kind of thing is a pretty flexible solution, but I realize this may not
      be so easy to implement for all platforms.... I'm not sure if I like the
      idea of locking things down at a pre-release level (1999) of the spec, and
      yet at the same time, there also may be older implementations that we want
      to be compatible with. My gut says to accept them all for a little while,
      deprecating 1999 and 2000 in new revisions of implementations.

      Oop - that's a start, but gotta go for now, one more message to queue before
      touchdown. More tomorrow.

      --Glen
    • Manish Balsara
      Paul I would agree with you that, null/missing values must have xsi:null, otherwise achieving interoperatability would be difficult, since different
      Message 2 of 13 , Apr 1, 2001
      • 0 Attachment
        Paul

        I would agree with you that, null/missing values must have xsi:null,
        otherwise achieving interoperatability would be difficult, since
        different implementations would interpret missing elements differently.

        There might be a way to represent missing elements in arrays by using the
        SOAP-ENC:position attribute (defined in Section 5.4.2.2 of SOAP spec).
        Each element in the array, would define the position in the array and skip
        the missing elements.

        manish

        On Sun, 1 Apr 2001, Paul Kulchenko wrote:

        > <html><body>
        > <tt>
        > Though it might be the case, but OMISSION of the element may be<BR>
        > treated as null -OR- default value on server side and in that case<BR>
        > client is NOT ABLE to tell that it's NULL and not a default case. One<BR>
        > question is still open, how to encode array if some elements are<BR>
        > null. If you omit something it won't be deserialized properly. Still<BR>
        > think it should be <something xsi:null=1/>.<BR>
        > <BR>
        > Best wishes, Paul.<BR>
        > <BR>
        > --- yahoo@... wrote:<BR>
        > > All the the forms you cite are technically valid.  However, the<BR>
        > > only <BR>
        > > form that I know of that integrates well with RDF and with semi-<BR>
        > > structured databases is OMISSION OF THE ELEMENT.  Looking into the <BR>
        > > future a little, I think that integration with RDF and such<BR>
        > > databases <BR>
        > > is important to keep our reengineering costs low and our data<BR>
        > > re-use <BR>
        > > high, so I recommend that a NULL be espressed by OMISSION OF THE <BR>
        > > ELEMENT.<BR>
        > > <BR>
        > > For example, given a structure of value like<BR>
        > > <BR>
        > >   new Foo("a", null, "c")<BR>
        > > <BR>
        > > I recommend a serialization of form like<BR>
        > > <BR>
        > >   <Foo><BR>
        > >     <m1>a</m1><BR>
        > >     <m3>c</m3><BR>
        > >   </Foo><BR>
        > > <BR>
        > > I realize that this is not the most convenient answer for some <BR>
        > > existing software, so I do not recommend it lightly but only after <BR>
        > > some consideration and conclusion that it will pay us back because<BR>
        > > it <BR>
        > > allows more integration going forward.<BR>
        > > <BR>
        > > <BR>
        > > <BR>
        > > --- In soapbuilders@y..., "Dave Winer" <dave@u...> wrote:<BR>
        > > > Confusion.<BR>
        > > > <BR>
        > > > Bottom-line.<BR>
        > > > <BR>
        > > > Is <nil xsi:null="1"/> OK with you as a way of representing nil<BR>
        > > or <BR>
        > > null or<BR>
        > > > whatever in SOAP 1.1 as of 4/1/01?<BR>
        > > > <BR>
        > > > If not, what do you think is the right way to represent<BR>
        > > nothingness <BR>
        > > or<BR>
        > > > voidness or emptyness?<BR>
        > > > <BR>
        > > > Dave<BR>
        > > > <BR>
        > > > <BR>
        > > > ----- Original Message -----<BR>
        > > > From: <yahoo@s...><BR>
        > > > To: <soapbuilders@y...><BR>
        > > > Sent: Sunday, April 01, 2001 5:58 PM<BR>
        > > > Subject: [soapbuilders] Re: Re-engaging<BR>
        > > > <BR>
        > > > <BR>
        > > > > Hello.  I'm trying to catch up now with the huge volume of <BR>
        > > discussion<BR>
        > > > > here, and, since I am not yet caught up, I will sometimes lack <BR>
        > > some<BR>
        > > > > of the context of a posting or will comment on something in <BR>
        > > advance<BR>
        > > > > of many subsequent comments.  If you can tolerate that, thank<BR>
        > > you.<BR>
        > > > ><BR>
        > > > > Glen Daniels wrote "Re: null params in the BDG - I haven't seen<BR>
        > > <BR>
        > > the<BR>
        > > > > latest version, just the mails, so I just want to make sure<BR>
        > > it's<BR>
        > > > > clear in the text that the "nil" element name is not required -<BR>
        > > <BR>
        > > i.e<BR>
        > > > > <thisParam xsi:null="1"/> is just as good.  A nit, to be<BR>
        > > sure..."<BR>
        > > > ><BR>
        > > > > There is much to be said about this.<BR>
        > > > ><BR>
        > > > > xsi:null has problems.  For one, while the namespace referenced<BR>
        > > > > by "xsi" contained an attribute called "null" at the time the<BR>
        > > SOAP<BR>
        > > > > 1.1 specification was written, the Proposed Recommendation <BR>
        > > version of<BR>
        > > > > the W3C XML Schemas specification, March 2001, no longer<BR>
        > > contains <BR>
        > > an<BR>
        > > > > attribute of that name.  This puts its use on pretty thin ice <BR>
        > > going<BR>
        > > > > forward.<BR>
        > > > ><BR>
        > > > > There is a similar attribute, now called "nil", described by<BR>
        > > the<BR>
        > > > > Schemas specification.  It was renamed specifically to disclaim<BR>
        > > <BR>
        > > any<BR>
        > > > > definite relation to the idea of "null" in a programming<BR>
        > > language <BR>
        > > or<BR>
        > > > > database.<BR>
        > > > ><BR>
        > > > > This does not, ipso facto, mean that SOAP 1.1 messages may not<BR>
        > > use<BR>
        > > > > xsi:nil to signal null (whatever it is that null means).  The<BR>
        > > > > relevant statement here is item nine in section 5.1 of the SOAP<BR>
        > > <BR>
        > > 1.1<BR>
        > > > > specification, which says, roughly, that a "null" (whatever a<BR>
        > > null<BR>
        > > > > is) may be represented by (a) omission of the element that<BR>
        > > would <BR>
        > > have<BR>
        > > > > represented a value, (b) presence of the element that would<BR>
        > > have<BR>
        > > > > contained a value, but now bearing an xsi:null='1' attribute,<BR>
        > > or <BR>
        > > (c)<BR>
        > > > > any other signal that is agreed on by the communicating <BR>
        > > applications.<BR>
        > > > ><BR>
        > > > > Consequently, xsi:nil is legal, under clause (c) above, but<BR>
        > > would<BR>
        > > > > obviously benefit from some broad agreement on its use.<BR>
        > > > ><BR>
        > > > > That said, however, there are reasons to prefer omission of an<BR>
        > > > > element (option a) rather than presence with a special<BR>
        > > attribute<BR>
        > > > > (option b). These reasons will not generally be apparent if one<BR>
        > > is<BR>
        > > > > only considering RPC, nor will they typically be clear in the <BR>
        > > context<BR>
        > > > > of programming language structures.  Where the difference<BR>
        > > matters <BR>
        > > is<BR>
        > > > > with databases, which are evolving to support a structure<BR>
        > > > > called "semi-structured" data, and in that situation an omitted<BR>
        > > > > element is very different from a present element with an <BR>
        > > attribute.<BR>
        > > > > The RDF Activity at W3C is also an example of a domain in which<BR>
        > > <BR>
        > > semi-<BR>
        > > > > structured data is important.<BR>
        > > > ><BR>
        > > > > The omitted element form corresponds much more closely with a<BR>
        > > > > database NULL and with semi-structured data.  For this reason,<BR>
        > > > > believing that we want to have a serialization format that<BR>
        > > works <BR>
        > > well<BR>
        > > > > with databases and RDF as well as with traditional programming<BR>
        > > > > languages, I favor consistently representing a null by omitting<BR>
        > > <BR>
        > > the<BR>
        > > > > corresponding element.<BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > > To unsubscribe from this group, send an email to:<BR>
        > > > > soapbuilders-unsubscribe@y...<BR>
        > > > ><BR>
        > > > ><BR>
        > > > ><BR>
        > > > > Your use of Yahoo! Groups is subject to <BR>
        > > <a href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a><BR>
        > > > ><BR>
        > > > ><BR>
        > > <BR>
        > > <BR>
        > > ------------------------ Yahoo! Groups Sponsor<BR>
        > > <BR>
        > > To unsubscribe from this group, send an email to:<BR>
        > > soapbuilders-unsubscribe@yahoogroups.com<BR>
        > > <BR>
        > >  <BR>
        > > <BR>
        > > Your use of Yahoo! Groups is subject to<BR>
        > > <a href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a> <BR>
        > > <BR>
        > > <BR>
        > <BR>
        > <BR>
        > __________________________________________________<BR>
        > Do You Yahoo!?<BR>
        > Get email at your own domain with Yahoo! Mail. <BR>
        > <a href="http://personal.mail.yahoo.com/?.refer=text">http://personal.mail.yahoo.com/?.refer=text</a><BR>
        > </tt>
        >
        > <br>
        >
        > <!-- |**|begin egp html banner|**| -->
        >
        > <table border=0 cellspacing=0 cellpadding=2>
        > <tr bgcolor=#FFFFCC>
        > <td align=center><font size="-1" color=#003399><b>Yahoo! Groups Sponsor</b></font></td>
        > </tr>
        > <tr bgcolor=#FFFFFF>
        > <td width=470><a href="http://rd.yahoo.com/M=162801.1342233.2934637.1279955/D=egroupmail/S=1700701014:N/A=599082/*http://www.knowledgestorm.com/jump_white.html?c=Yahoo&n=eLert_ComputersInternet_CommNetworking_WhiteGridOptions&t=ad" target="_top"><img width=468 height=60 src="http://us.a1.yimg.com/us.yimg.com/a/kn/knowledge_storm/elerts_n_whitegridoptions.gif" alt="Click Here to Find Software Faster" border=0><br>Click Here to Find Software Faster</a></td>
        > </tr>
        > <tr><td><img alt="" width=1 height=1 src="http://us.adserver.yahoo.com/l?M=162801.1342233.2934637.1279955/D=egroupmail/S=1700701014:N/A=599082/rand=491038381"></td></tr>
        > </table>
        >
        > <!-- |**|end egp html banner|**| -->
        >
        >
        > <br>
        > <tt>
        > To unsubscribe from this group, send an email to:<BR>
        > soapbuilders-unsubscribe@yahoogroups.com<BR>
        > <BR>
        > </tt>
        > <br>
        >
        > <br>
        > <tt>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt>
        > </br>
        >
        > </body></html>
        >
        >
      • yahoo@strongbrains.com
        Hello. I m trying to catch up now with the huge volume of discussion here, and, since I am not yet caught up, I will sometimes lack some of the context of a
        Message 3 of 13 , Apr 1, 2001
        • 0 Attachment
          Hello. I'm trying to catch up now with the huge volume of discussion
          here, and, since I am not yet caught up, I will sometimes lack some
          of the context of a posting or will comment on something in advance
          of many subsequent comments. If you can tolerate that, thank you.

          Glen Daniels wrote "Re: null params in the BDG - I haven't seen the
          latest version, just the mails, so I just want to make sure it's
          clear in the text that the "nil" element name is not required - i.e
          <thisParam xsi:null="1"/> is just as good. A nit, to be sure..."

          There is much to be said about this.

          xsi:null has problems. For one, while the namespace referenced
          by "xsi" contained an attribute called "null" at the time the SOAP
          1.1 specification was written, the Proposed Recommendation version of
          the W3C XML Schemas specification, March 2001, no longer contains an
          attribute of that name. This puts its use on pretty thin ice going
          forward.

          There is a similar attribute, now called "nil", described by the
          Schemas specification. It was renamed specifically to disclaim any
          definite relation to the idea of "null" in a programming language or
          database.

          This does not, ipso facto, mean that SOAP 1.1 messages may not use
          xsi:nil to signal null (whatever it is that null means). The
          relevant statement here is item nine in section 5.1 of the SOAP 1.1
          specification, which says, roughly, that a "null" (whatever a null
          is) may be represented by (a) omission of the element that would have
          represented a value, (b) presence of the element that would have
          contained a value, but now bearing an xsi:null='1' attribute, or (c)
          any other signal that is agreed on by the communicating applications.

          Consequently, xsi:nil is legal, under clause (c) above, but would
          obviously benefit from some broad agreement on its use.

          That said, however, there are reasons to prefer omission of an
          element (option a) rather than presence with a special attribute
          (option b). These reasons will not generally be apparent if one is
          only considering RPC, nor will they typically be clear in the context
          of programming language structures. Where the difference matters is
          with databases, which are evolving to support a structure
          called "semi-structured" data, and in that situation an omitted
          element is very different from a present element with an attribute.
          The RDF Activity at W3C is also an example of a domain in which semi-
          structured data is important.

          The omitted element form corresponds much more closely with a
          database NULL and with semi-structured data. For this reason,
          believing that we want to have a serialization format that works well
          with databases and RDF as well as with traditional programming
          languages, I favor consistently representing a null by omitting the
          corresponding element.
        • Dave Winer
          Confusion. Bottom-line. Is OK with you as a way of representing nil or null or whatever in SOAP 1.1 as of 4/1/01? If not, what do you think
          Message 4 of 13 , Apr 1, 2001
          • 0 Attachment
            Confusion.

            Bottom-line.

            Is <nil xsi:null="1"/> OK with you as a way of representing nil or null or
            whatever in SOAP 1.1 as of 4/1/01?

            If not, what do you think is the right way to represent nothingness or
            voidness or emptyness?

            Dave


            ----- Original Message -----
            From: <yahoo@...>
            To: <soapbuilders@yahoogroups.com>
            Sent: Sunday, April 01, 2001 5:58 PM
            Subject: [soapbuilders] Re: Re-engaging


            > Hello. I'm trying to catch up now with the huge volume of discussion
            > here, and, since I am not yet caught up, I will sometimes lack some
            > of the context of a posting or will comment on something in advance
            > of many subsequent comments. If you can tolerate that, thank you.
            >
            > Glen Daniels wrote "Re: null params in the BDG - I haven't seen the
            > latest version, just the mails, so I just want to make sure it's
            > clear in the text that the "nil" element name is not required - i.e
            > <thisParam xsi:null="1"/> is just as good. A nit, to be sure..."
            >
            > There is much to be said about this.
            >
            > xsi:null has problems. For one, while the namespace referenced
            > by "xsi" contained an attribute called "null" at the time the SOAP
            > 1.1 specification was written, the Proposed Recommendation version of
            > the W3C XML Schemas specification, March 2001, no longer contains an
            > attribute of that name. This puts its use on pretty thin ice going
            > forward.
            >
            > There is a similar attribute, now called "nil", described by the
            > Schemas specification. It was renamed specifically to disclaim any
            > definite relation to the idea of "null" in a programming language or
            > database.
            >
            > This does not, ipso facto, mean that SOAP 1.1 messages may not use
            > xsi:nil to signal null (whatever it is that null means). The
            > relevant statement here is item nine in section 5.1 of the SOAP 1.1
            > specification, which says, roughly, that a "null" (whatever a null
            > is) may be represented by (a) omission of the element that would have
            > represented a value, (b) presence of the element that would have
            > contained a value, but now bearing an xsi:null='1' attribute, or (c)
            > any other signal that is agreed on by the communicating applications.
            >
            > Consequently, xsi:nil is legal, under clause (c) above, but would
            > obviously benefit from some broad agreement on its use.
            >
            > That said, however, there are reasons to prefer omission of an
            > element (option a) rather than presence with a special attribute
            > (option b). These reasons will not generally be apparent if one is
            > only considering RPC, nor will they typically be clear in the context
            > of programming language structures. Where the difference matters is
            > with databases, which are evolving to support a structure
            > called "semi-structured" data, and in that situation an omitted
            > element is very different from a present element with an attribute.
            > The RDF Activity at W3C is also an example of a domain in which semi-
            > structured data is important.
            >
            > The omitted element form corresponds much more closely with a
            > database NULL and with semi-structured data. For this reason,
            > believing that we want to have a serialization format that works well
            > with databases and RDF as well as with traditional programming
            > languages, I favor consistently representing a null by omitting the
            > corresponding element.
            >
            >
            >
            >
            >
            >
            >
            >
            > 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@strongbrains.com
            All the the forms you cite are technically valid. However, the only form that I know of that integrates well with RDF and with semi- structured databases is
            Message 5 of 13 , Apr 1, 2001
            • 0 Attachment
              All the the forms you cite are technically valid. However, the only
              form that I know of that integrates well with RDF and with semi-
              structured databases is OMISSION OF THE ELEMENT. Looking into the
              future a little, I think that integration with RDF and such databases
              is important to keep our reengineering costs low and our data re-use
              high, so I recommend that a NULL be espressed by OMISSION OF THE
              ELEMENT.

              For example, given a structure of value like

              new Foo("a", null, "c")

              I recommend a serialization of form like

              <Foo>
              <m1>a</m1>
              <m3>c</m3>
              </Foo>

              I realize that this is not the most convenient answer for some
              existing software, so I do not recommend it lightly but only after
              some consideration and conclusion that it will pay us back because it
              allows more integration going forward.



              --- In soapbuilders@y..., "Dave Winer" <dave@u...> wrote:
              > Confusion.
              >
              > Bottom-line.
              >
              > Is <nil xsi:null="1"/> OK with you as a way of representing nil or
              null or
              > whatever in SOAP 1.1 as of 4/1/01?
              >
              > If not, what do you think is the right way to represent nothingness
              or
              > voidness or emptyness?
              >
              > Dave
              >
              >
              > ----- Original Message -----
              > From: <yahoo@s...>
              > To: <soapbuilders@y...>
              > Sent: Sunday, April 01, 2001 5:58 PM
              > Subject: [soapbuilders] Re: Re-engaging
              >
              >
              > > Hello. I'm trying to catch up now with the huge volume of
              discussion
              > > here, and, since I am not yet caught up, I will sometimes lack
              some
              > > of the context of a posting or will comment on something in
              advance
              > > of many subsequent comments. If you can tolerate that, thank you.
              > >
              > > Glen Daniels wrote "Re: null params in the BDG - I haven't seen
              the
              > > latest version, just the mails, so I just want to make sure it's
              > > clear in the text that the "nil" element name is not required -
              i.e
              > > <thisParam xsi:null="1"/> is just as good. A nit, to be sure..."
              > >
              > > There is much to be said about this.
              > >
              > > xsi:null has problems. For one, while the namespace referenced
              > > by "xsi" contained an attribute called "null" at the time the SOAP
              > > 1.1 specification was written, the Proposed Recommendation
              version of
              > > the W3C XML Schemas specification, March 2001, no longer contains
              an
              > > attribute of that name. This puts its use on pretty thin ice
              going
              > > forward.
              > >
              > > There is a similar attribute, now called "nil", described by the
              > > Schemas specification. It was renamed specifically to disclaim
              any
              > > definite relation to the idea of "null" in a programming language
              or
              > > database.
              > >
              > > This does not, ipso facto, mean that SOAP 1.1 messages may not use
              > > xsi:nil to signal null (whatever it is that null means). The
              > > relevant statement here is item nine in section 5.1 of the SOAP
              1.1
              > > specification, which says, roughly, that a "null" (whatever a null
              > > is) may be represented by (a) omission of the element that would
              have
              > > represented a value, (b) presence of the element that would have
              > > contained a value, but now bearing an xsi:null='1' attribute, or
              (c)
              > > any other signal that is agreed on by the communicating
              applications.
              > >
              > > Consequently, xsi:nil is legal, under clause (c) above, but would
              > > obviously benefit from some broad agreement on its use.
              > >
              > > That said, however, there are reasons to prefer omission of an
              > > element (option a) rather than presence with a special attribute
              > > (option b). These reasons will not generally be apparent if one is
              > > only considering RPC, nor will they typically be clear in the
              context
              > > of programming language structures. Where the difference matters
              is
              > > with databases, which are evolving to support a structure
              > > called "semi-structured" data, and in that situation an omitted
              > > element is very different from a present element with an
              attribute.
              > > The RDF Activity at W3C is also an example of a domain in which
              semi-
              > > structured data is important.
              > >
              > > The omitted element form corresponds much more closely with a
              > > database NULL and with semi-structured data. For this reason,
              > > believing that we want to have a serialization format that works
              well
              > > with databases and RDF as well as with traditional programming
              > > languages, I favor consistently representing a null by omitting
              the
              > > corresponding element.
              > >
              > >
              > >
              > >
              > >
              > >
              > >
              > >
              > > To unsubscribe from this group, send an email to:
              > > soapbuilders-unsubscribe@y...
              > >
              > >
              > >
              > > Your use of Yahoo! Groups is subject to
              http://docs.yahoo.com/info/terms/
              > >
              > >
            • Paul Kulchenko
              Though it might be the case, but OMISSION of the element may be treated as null -OR- default value on server side and in that case client is NOT ABLE to tell
              Message 6 of 13 , Apr 1, 2001
              • 0 Attachment
                Though it might be the case, but OMISSION of the element may be
                treated as null -OR- default value on server side and in that case
                client is NOT ABLE to tell that it's NULL and not a default case. One
                question is still open, how to encode array if some elements are
                null. If you omit something it won't be deserialized properly. Still
                think it should be <something xsi:null=1/>.

                Best wishes, Paul.

                --- yahoo@... wrote:
                > All the the forms you cite are technically valid. However, the
                > only
                > form that I know of that integrates well with RDF and with semi-
                > structured databases is OMISSION OF THE ELEMENT. Looking into the
                > future a little, I think that integration with RDF and such
                > databases
                > is important to keep our reengineering costs low and our data
                > re-use
                > high, so I recommend that a NULL be espressed by OMISSION OF THE
                > ELEMENT.
                >
                > For example, given a structure of value like
                >
                > new Foo("a", null, "c")
                >
                > I recommend a serialization of form like
                >
                > <Foo>
                > <m1>a</m1>
                > <m3>c</m3>
                > </Foo>
                >
                > I realize that this is not the most convenient answer for some
                > existing software, so I do not recommend it lightly but only after
                > some consideration and conclusion that it will pay us back because
                > it
                > allows more integration going forward.
                >
                >
                >
                > --- In soapbuilders@y..., "Dave Winer" <dave@u...> wrote:
                > > Confusion.
                > >
                > > Bottom-line.
                > >
                > > Is <nil xsi:null="1"/> OK with you as a way of representing nil
                > or
                > null or
                > > whatever in SOAP 1.1 as of 4/1/01?
                > >
                > > If not, what do you think is the right way to represent
                > nothingness
                > or
                > > voidness or emptyness?
                > >
                > > Dave
                > >
                > >
                > > ----- Original Message -----
                > > From: <yahoo@s...>
                > > To: <soapbuilders@y...>
                > > Sent: Sunday, April 01, 2001 5:58 PM
                > > Subject: [soapbuilders] Re: Re-engaging
                > >
                > >
                > > > Hello. I'm trying to catch up now with the huge volume of
                > discussion
                > > > here, and, since I am not yet caught up, I will sometimes lack
                > some
                > > > of the context of a posting or will comment on something in
                > advance
                > > > of many subsequent comments. If you can tolerate that, thank
                > you.
                > > >
                > > > Glen Daniels wrote "Re: null params in the BDG - I haven't seen
                >
                > the
                > > > latest version, just the mails, so I just want to make sure
                > it's
                > > > clear in the text that the "nil" element name is not required -
                >
                > i.e
                > > > <thisParam xsi:null="1"/> is just as good. A nit, to be
                > sure..."
                > > >
                > > > There is much to be said about this.
                > > >
                > > > xsi:null has problems. For one, while the namespace referenced
                > > > by "xsi" contained an attribute called "null" at the time the
                > SOAP
                > > > 1.1 specification was written, the Proposed Recommendation
                > version of
                > > > the W3C XML Schemas specification, March 2001, no longer
                > contains
                > an
                > > > attribute of that name. This puts its use on pretty thin ice
                > going
                > > > forward.
                > > >
                > > > There is a similar attribute, now called "nil", described by
                > the
                > > > Schemas specification. It was renamed specifically to disclaim
                >
                > any
                > > > definite relation to the idea of "null" in a programming
                > language
                > or
                > > > database.
                > > >
                > > > This does not, ipso facto, mean that SOAP 1.1 messages may not
                > use
                > > > xsi:nil to signal null (whatever it is that null means). The
                > > > relevant statement here is item nine in section 5.1 of the SOAP
                >
                > 1.1
                > > > specification, which says, roughly, that a "null" (whatever a
                > null
                > > > is) may be represented by (a) omission of the element that
                > would
                > have
                > > > represented a value, (b) presence of the element that would
                > have
                > > > contained a value, but now bearing an xsi:null='1' attribute,
                > or
                > (c)
                > > > any other signal that is agreed on by the communicating
                > applications.
                > > >
                > > > Consequently, xsi:nil is legal, under clause (c) above, but
                > would
                > > > obviously benefit from some broad agreement on its use.
                > > >
                > > > That said, however, there are reasons to prefer omission of an
                > > > element (option a) rather than presence with a special
                > attribute
                > > > (option b). These reasons will not generally be apparent if one
                > is
                > > > only considering RPC, nor will they typically be clear in the
                > context
                > > > of programming language structures. Where the difference
                > matters
                > is
                > > > with databases, which are evolving to support a structure
                > > > called "semi-structured" data, and in that situation an omitted
                > > > element is very different from a present element with an
                > attribute.
                > > > The RDF Activity at W3C is also an example of a domain in which
                >
                > semi-
                > > > structured data is important.
                > > >
                > > > The omitted element form corresponds much more closely with a
                > > > database NULL and with semi-structured data. For this reason,
                > > > believing that we want to have a serialization format that
                > works
                > well
                > > > with databases and RDF as well as with traditional programming
                > > > languages, I favor consistently representing a null by omitting
                >
                > the
                > > > corresponding element.
                > > >
                > > >
                > > >
                > > >
                > > >
                > > >
                > > >
                > > >
                > > > To unsubscribe from this group, send an email to:
                > > > soapbuilders-unsubscribe@y...
                > > >
                > > >
                > > >
                > > > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                > > >
                > > >
                >
                >
                > ------------------------ Yahoo! Groups Sponsor
                >
                > 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/
                >
                >


                __________________________________________________
                Do You Yahoo!?
                Get email at your own domain with Yahoo! Mail.
                http://personal.mail.yahoo.com/?.refer=text
              • Andrew Layman
                It is probably sufficient to have only the element following the missing elements indicate its position using the SOAP-ENC:position attribute. Elements without
                Message 7 of 13 , Apr 1, 2001
                • 0 Attachment
                  It is probably sufficient to have only the element following the missing
                  elements indicate its position using the SOAP-ENC:position attribute.
                  Elements without this attribute follow in order the preceding position.
                  ----- Original Message -----
                  From: "Manish Balsara" <manishb@...>
                  To: <soapbuilders@yahoogroups.com>
                  Sent: Sunday, April 01, 2001 2:58 PM
                  Subject: Re: [soapbuilders] Re: Re-engaging


                  Paul

                  I would agree with you that, null/missing values must have xsi:null,
                  otherwise achieving interoperatability would be difficult, since
                  different implementations would interpret missing elements differently.

                  There might be a way to represent missing elements in arrays by using the
                  SOAP-ENC:position attribute (defined in Section 5.4.2.2 of SOAP spec).
                  Each element in the array, would define the position in the array and skip
                  the missing elements.

                  manish

                  On Sun, 1 Apr 2001, Paul Kulchenko wrote:

                  > <html><body>
                  > <tt>
                  > Though it might be the case, but OMISSION of the element may be<BR>
                  > treated as null -OR- default value on server side and in that case<BR>
                  > client is NOT ABLE to tell that it's NULL and not a default case. One<BR>
                  > question is still open, how to encode array if some elements are<BR>
                  > null. If you omit something it won't be deserialized properly. Still<BR>
                  > think it should be <something xsi:null=1/>.<BR>
                  > <BR>
                  > Best wishes, Paul.<BR>
                  > <BR>
                  > --- yahoo@... wrote:<BR>
                  > > All the the forms you cite are technically valid.  However,
                  the<BR>
                  > > only <BR>
                  > > form that I know of that integrates well with RDF and with semi-<BR>
                  > > structured databases is OMISSION OF THE ELEMENT.  Looking into
                  the <BR>
                  > > future a little, I think that integration with RDF and such<BR>
                  > > databases <BR>
                  > > is important to keep our reengineering costs low and our data<BR>
                  > > re-use <BR>
                  > > high, so I recommend that a NULL be espressed by OMISSION OF THE <BR>
                  > > ELEMENT.<BR>
                  > > <BR>
                  > > For example, given a structure of value like<BR>
                  > > <BR>
                  > >   new Foo("a", null, "c")<BR>
                  > > <BR>
                  > > I recommend a serialization of form like<BR>
                  > > <BR>
                  > >   <Foo><BR>
                  > >     <m1>a</m1><BR>
                  > >     <m3>c</m3><BR>
                  > >   </Foo><BR>
                  > > <BR>
                  > > I realize that this is not the most convenient answer for some <BR>
                  > > existing software, so I do not recommend it lightly but only after
                  <BR>
                  > > some consideration and conclusion that it will pay us back
                  because<BR>
                  > > it <BR>
                  > > allows more integration going forward.<BR>
                  > > <BR>
                  > > <BR>
                  > > <BR>
                  > > --- In soapbuilders@y..., "Dave Winer" <dave@u...>
                  wrote:<BR>
                  > > > Confusion.<BR>
                  > > > <BR>
                  > > > Bottom-line.<BR>
                  > > > <BR>
                  > > > Is <nil xsi:null="1"/> OK with you as a way of
                  representing nil<BR>
                  > > or <BR>
                  > > null or<BR>
                  > > > whatever in SOAP 1.1 as of 4/1/01?<BR>
                  > > > <BR>
                  > > > If not, what do you think is the right way to represent<BR>
                  > > nothingness <BR>
                  > > or<BR>
                  > > > voidness or emptyness?<BR>
                  > > > <BR>
                  > > > Dave<BR>
                  > > > <BR>
                  > > > <BR>
                  > > > ----- Original Message -----<BR>
                  > > > From: <yahoo@s...><BR>
                  > > > To: <soapbuilders@y...><BR>
                  > > > Sent: Sunday, April 01, 2001 5:58 PM<BR>
                  > > > Subject: [soapbuilders] Re: Re-engaging<BR>
                  > > > <BR>
                  > > > <BR>
                  > > > > Hello.  I'm trying to catch up now with the huge
                  volume of <BR>
                  > > discussion<BR>
                  > > > > here, and, since I am not yet caught up, I will sometimes
                  lack <BR>
                  > > some<BR>
                  > > > > of the context of a posting or will comment on something in
                  <BR>
                  > > advance<BR>
                  > > > > of many subsequent comments.  If you can tolerate
                  that, thank<BR>
                  > > you.<BR>
                  > > > ><BR>
                  > > > > Glen Daniels wrote "Re: null params in the BDG - I
                  haven't seen<BR>
                  > > <BR>
                  > > the<BR>
                  > > > > latest version, just the mails, so I just want to make
                  sure<BR>
                  > > it's<BR>
                  > > > > clear in the text that the "nil" element name is
                  not required -<BR>
                  > > <BR>
                  > > i.e<BR>
                  > > > > <thisParam xsi:null="1"/> is just as
                  good.  A nit, to be<BR>
                  > > sure..."<BR>
                  > > > ><BR>
                  > > > > There is much to be said about this.<BR>
                  > > > ><BR>
                  > > > > xsi:null has problems.  For one, while the namespace
                  referenced<BR>
                  > > > > by "xsi" contained an attribute called
                  "null" at the time the<BR>
                  > > SOAP<BR>
                  > > > > 1.1 specification was written, the Proposed Recommendation
                  <BR>
                  > > version of<BR>
                  > > > > the W3C XML Schemas specification, March 2001, no
                  longer<BR>
                  > > contains <BR>
                  > > an<BR>
                  > > > > attribute of that name.  This puts its use on pretty
                  thin ice <BR>
                  > > going<BR>
                  > > > > forward.<BR>
                  > > > ><BR>
                  > > > > There is a similar attribute, now called "nil",
                  described by<BR>
                  > > the<BR>
                  > > > > Schemas specification.  It was renamed specifically to
                  disclaim<BR>
                  > > <BR>
                  > > any<BR>
                  > > > > definite relation to the idea of "null" in a
                  programming<BR>
                  > > language <BR>
                  > > or<BR>
                  > > > > database.<BR>
                  > > > ><BR>
                  > > > > This does not, ipso facto, mean that SOAP 1.1 messages may
                  not<BR>
                  > > use<BR>
                  > > > > xsi:nil to signal null (whatever it is that null
                  means).  The<BR>
                  > > > > relevant statement here is item nine in section 5.1 of the
                  SOAP<BR>
                  > > <BR>
                  > > 1.1<BR>
                  > > > > specification, which says, roughly, that a "null"
                  (whatever a<BR>
                  > > null<BR>
                  > > > > is) may be represented by (a) omission of the element
                  that<BR>
                  > > would <BR>
                  > > have<BR>
                  > > > > represented a value, (b) presence of the element that
                  would<BR>
                  > > have<BR>
                  > > > > contained a value, but now bearing an xsi:null='1'
                  attribute,<BR>
                  > > or <BR>
                  > > (c)<BR>
                  > > > > any other signal that is agreed on by the communicating
                  <BR>
                  > > applications.<BR>
                  > > > ><BR>
                  > > > > Consequently, xsi:nil is legal, under clause (c) above,
                  but<BR>
                  > > would<BR>
                  > > > > obviously benefit from some broad agreement on its use.<BR>
                  > > > ><BR>
                  > > > > That said, however, there are reasons to prefer omission of
                  an<BR>
                  > > > > element (option a) rather than presence with a special<BR>
                  > > attribute<BR>
                  > > > > (option b). These reasons will not generally be apparent if
                  one<BR>
                  > > is<BR>
                  > > > > only considering RPC, nor will they typically be clear in
                  the <BR>
                  > > context<BR>
                  > > > > of programming language structures.  Where the
                  difference<BR>
                  > > matters <BR>
                  > > is<BR>
                  > > > > with databases, which are evolving to support a
                  structure<BR>
                  > > > > called "semi-structured" data, and in that
                  situation an omitted<BR>
                  > > > > element is very different from a present element with an
                  <BR>
                  > > attribute.<BR>
                  > > > > The RDF Activity at W3C is also an example of a domain in
                  which<BR>
                  > > <BR>
                  > > semi-<BR>
                  > > > > structured data is important.<BR>
                  > > > ><BR>
                  > > > > The omitted element form corresponds much more closely with
                  a<BR>
                  > > > > database NULL and with semi-structured data.  For this
                  reason,<BR>
                  > > > > believing that we want to have a serialization format
                  that<BR>
                  > > works <BR>
                  > > well<BR>
                  > > > > with databases and RDF as well as with traditional
                  programming<BR>
                  > > > > languages, I favor consistently representing a null by
                  omitting<BR>
                  > > <BR>
                  > > the<BR>
                  > > > > corresponding element.<BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > > To unsubscribe from this group, send an email to:<BR>
                  > > > > soapbuilders-unsubscribe@y...<BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > > > Your use of Yahoo! Groups is subject to <BR>
                  > > <a
                  href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</
                  a><BR>
                  > > > ><BR>
                  > > > ><BR>
                  > > <BR>
                  > > <BR>
                  > > ------------------------ Yahoo! Groups Sponsor<BR>
                  > > <BR>
                  > > To unsubscribe from this group, send an email to:<BR>
                  > > soapbuilders-unsubscribe@yahoogroups.com<BR>
                  > > <BR>
                  > >  <BR>
                  > > <BR>
                  > > Your use of Yahoo! Groups is subject to<BR>
                  > > <a
                  href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</
                  a> <BR>
                  > > <BR>
                  > > <BR>
                  > <BR>
                  > <BR>
                  > __________________________________________________<BR>
                  > Do You Yahoo!?<BR>
                  > Get email at your own domain with Yahoo! Mail. <BR>
                  > <a
                  href="http://personal.mail.yahoo.com/?.refer=text">http://personal.mail.yaho
                  o.com/?.refer=text</a><BR>
                  > </tt>
                  >
                  > <br>
                  >
                  > <!-- |**|begin egp html banner|**| -->
                  >
                  > <table border=0 cellspacing=0 cellpadding=2>
                  > <tr bgcolor=#FFFFCC>
                  > <td align=center><font size="-1" color=#003399><b>Yahoo! Groups
                  Sponsor</b></font></td>
                  > </tr>
                  > <tr bgcolor=#FFFFFF>
                  > <td width=470><a
                  href="http://rd.yahoo.com/M=162801.1342233.2934637.1279955/D=egroupmail/S=17
                  00701014:N/A=599082/*http://www.knowledgestorm.com/jump_white.html?c=Yahoo&n
                  =eLert_ComputersInternet_CommNetworking_WhiteGridOptions&t=ad"
                  target="_top"><img width=468 height=60
                  src="http://us.a1.yimg.com/us.yimg.com/a/kn/knowledge_storm/elerts_n_whitegr
                  idoptions.gif" alt="Click Here to Find Software Faster" border=0><br>Click
                  Here to Find Software Faster</a></td>
                  > </tr>
                  > <tr><td><img alt="" width=1 height=1
                  src="http://us.adserver.yahoo.com/l?M=162801.1342233.2934637.1279955/D=egrou
                  pmail/S=1700701014:N/A=599082/rand=491038381"></td></tr>
                  > </table>
                  >
                  > <!-- |**|end egp html banner|**| -->
                  >
                  >
                  > <br>
                  > <tt>
                  > To unsubscribe from this group, send an email to:<BR>
                  > soapbuilders-unsubscribe@yahoogroups.com<BR>
                  > <BR>
                  > </tt>
                  > <br>
                  >
                  > <br>
                  > <tt>Your use of Yahoo! Groups is subject to the <a
                  href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt>
                  > </br>
                  >
                  > </body></html>
                  >
                  >



                  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/
                • Andrew Layman
                  Manish Balsara wrote that omission of an element might be ambiguous: does it represent a null value or a default value? This is a problem with nulls,
                  Message 8 of 13 , Apr 1, 2001
                  • 0 Attachment
                    Manish Balsara wrote that omission of an element might be ambiguous: does it
                    represent a "null" value or a default value?
                    This is a problem with nulls, generally, namely what does a "null"
                    represent? Related to the present question, it is even true that, in many
                    cases, nulls signal that default values should be inferred. There are no
                    definite semantics of "nulls." This is a well-known, huge problem, with any
                    system that attempts to use "nulls."

                    What we can hope to do is to use a representation that allows us to transfer
                    a programming-language "null" and that also is consistent with the
                    engineering disciplines that have given the most thought to the nulls
                    problem, specifically semi-structured databases and directed-labeled graph
                    data representations.
                  • Dave Winer
                    ... transfer a programming-language null and that also is consistent with the engineering disciplines that have given the most thought to the nulls problem,
                    Message 9 of 13 , Apr 1, 2001
                    • 0 Attachment
                      >>What we can hope to do is to use a representation that allows us to
                      transfer a programming-language "null" and that also is consistent with the
                      engineering disciplines that have given the most thought to the nulls
                      problem, specifically semi-structured databases and directed-labeled graph
                      data representations.

                      I totally agree. I almost thought you said "transport" instead of
                      "transfer". We can punt on the hard problem, and just accept a more modest
                      challenge, to model the kinds of structures our languages like to push
                      around. Null is a concept in many programming languages, I'm pretty sure
                      there are languages that don't have such a concept. This is why it has been
                      problematic in XML-RPC-land, in fact the mail list is discussing this (for
                      the 80th time) right now.

                      That's why I wanted to get a token into the BDG that clearly says that if
                      you have to move a null across the wire "this will work."

                      Dave
                    • Andrew Layman
                      There are a bunch of tokens that could be defined for nulls . Per the SOAP spec, any and all would be valid. Obviously, that is a problem for
                      Message 10 of 13 , Apr 1, 2001
                      • 0 Attachment
                        There are a bunch of tokens that could be defined for "nulls". Per the SOAP
                        spec, any and all would be valid. Obviously, that is a problem for
                        interoperability, so there is some motivation to agree on something more
                        specific. But more, we should have some motivation to agree on something
                        that does more than get us some interoperating applications this week. If
                        we can see that one choice will interoperate better with databases and some
                        of the advanced ideas in data representation, that it will avoid integration
                        problems going forward, then that should have some extra value to us. I have
                        been persuaded that, by this measure, the best way to represent a "null" is
                        to omit the element that would otherwise be present.

                        By the way, the problem with "null" is not that it is not present in some
                        programming languages, but rather that it is a single token with vastly
                        overloaded meanings and ambiguous functional definition. Check the SQL
                        literature or writings of Chris Date if you want extensive details.


                        ----- Original Message -----
                        From: "Dave Winer" <dave@...>
                        To: <soapbuilders@yahoogroups.com>
                        Sent: Sunday, April 01, 2001 8:37 PM
                        Subject: Re: [soapbuilders] Re: Re-engaging


                        >>What we can hope to do is to use a representation that allows us to
                        transfer a programming-language "null" and that also is consistent with the
                        engineering disciplines that have given the most thought to the nulls
                        problem, specifically semi-structured databases and directed-labeled graph
                        data representations.

                        I totally agree. I almost thought you said "transport" instead of
                        "transfer". We can punt on the hard problem, and just accept a more modest
                        challenge, to model the kinds of structures our languages like to push
                        around. Null is a concept in many programming languages, I'm pretty sure
                        there are languages that don't have such a concept. This is why it has been
                        problematic in XML-RPC-land, in fact the mail list is discussing this (for
                        the 80th time) right now.

                        That's why I wanted to get a token into the BDG that clearly says that if
                        you have to move a null across the wire "this will work."

                        Dave





                        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/
                      • Dave Winer
                        Cool, I m glad we agree on this. Now, here s what we have in the BDG right now. Here s a link to that part of the document.
                        Message 11 of 13 , Apr 1, 2001
                        • 0 Attachment
                          Cool, I'm glad we agree on this.

                          Now, here's what we have in the BDG right now.

                          <nil xsi:null="1"/>

                          Here's a link to that part of the document.

                          http://www.soapware.org/bdg#nullValues

                          As far as you know, is this a right way to express null?

                          To be very clear, I am not asking if it is *the* right way, just *a* right
                          way.

                          Dave



                          ----- Original Message -----
                          From: "Andrew Layman" <yahoo@...>
                          To: <soapbuilders@yahoogroups.com>
                          Sent: Sunday, April 01, 2001 9:00 PM
                          Subject: Re: [soapbuilders] Re: Re-engaging


                          > There are a bunch of tokens that could be defined for "nulls". Per the
                          SOAP
                          > spec, any and all would be valid. Obviously, that is a problem for
                          > interoperability, so there is some motivation to agree on something more
                          > specific. But more, we should have some motivation to agree on something
                          > that does more than get us some interoperating applications this week. If
                          > we can see that one choice will interoperate better with databases and
                          some
                          > of the advanced ideas in data representation, that it will avoid
                          integration
                          > problems going forward, then that should have some extra value to us. I
                          have
                          > been persuaded that, by this measure, the best way to represent a "null"
                          is
                          > to omit the element that would otherwise be present.
                          >
                          > By the way, the problem with "null" is not that it is not present in some
                          > programming languages, but rather that it is a single token with vastly
                          > overloaded meanings and ambiguous functional definition. Check the SQL
                          > literature or writings of Chris Date if you want extensive details.
                          >
                          >
                          > ----- Original Message -----
                          > From: "Dave Winer" <dave@...>
                          > To: <soapbuilders@yahoogroups.com>
                          > Sent: Sunday, April 01, 2001 8:37 PM
                          > Subject: Re: [soapbuilders] Re: Re-engaging
                          >
                          >
                          > >>What we can hope to do is to use a representation that allows us to
                          > transfer a programming-language "null" and that also is consistent with
                          the
                          > engineering disciplines that have given the most thought to the nulls
                          > problem, specifically semi-structured databases and directed-labeled graph
                          > data representations.
                          >
                          > I totally agree. I almost thought you said "transport" instead of
                          > "transfer". We can punt on the hard problem, and just accept a more modest
                          > challenge, to model the kinds of structures our languages like to push
                          > around. Null is a concept in many programming languages, I'm pretty sure
                          > there are languages that don't have such a concept. This is why it has
                          been
                          > problematic in XML-RPC-land, in fact the mail list is discussing this (for
                          > the 80th time) right now.
                          >
                          > That's why I wanted to get a token into the BDG that clearly says that if
                          > you have to move a null across the wire "this will work."
                          >
                          > Dave
                          >
                          >
                          >
                          >
                          >
                          > 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/
                          >
                          >
                          >
                          >
                          >
                          >
                          > 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/
                          >
                          >
                        • Andrew Layman
                          To be technically exact, my reading of the SOAP specification is that there is NO single right way to represent a null! However, (except in the unusual case
                          Message 12 of 13 , Apr 1, 2001
                          • 0 Attachment
                            To be technically exact, my reading of the SOAP specification is that there
                            is NO single right way to represent a null! However, (except in the unusual
                            case that your accessor is named "nil") there are three problems with the
                            example below:

                            1. The element name should be the accessor name (except in the case of
                            array elements or multi-referenced values).

                            2. There is no such attribute as xsi:null in the W3C XML Schema-defined
                            namespace.

                            3. Use of anything other than omission of the element appears to have
                            eventual integration problems with RDF and XML databases.

                            ----- Original Message -----
                            From: "Dave Winer" <dave@...>
                            To: <soapbuilders@yahoogroups.com>
                            Sent: Sunday, April 01, 2001 9:16 PM
                            Subject: Re: [soapbuilders] Re: Re-engaging


                            Cool, I'm glad we agree on this.

                            Now, here's what we have in the BDG right now.

                            <nil xsi:null="1"/>

                            Here's a link to that part of the document.

                            http://www.soapware.org/bdg#nullValues

                            As far as you know, is this a right way to express null?

                            To be very clear, I am not asking if it is *the* right way, just *a* right
                            way.

                            Dave



                            ----- Original Message -----
                            From: "Andrew Layman" <yahoo@...>
                            To: <soapbuilders@yahoogroups.com>
                            Sent: Sunday, April 01, 2001 9:00 PM
                            Subject: Re: [soapbuilders] Re: Re-engaging


                            > There are a bunch of tokens that could be defined for "nulls". Per the
                            SOAP
                            > spec, any and all would be valid. Obviously, that is a problem for
                            > interoperability, so there is some motivation to agree on something more
                            > specific. But more, we should have some motivation to agree on something
                            > that does more than get us some interoperating applications this week. If
                            > we can see that one choice will interoperate better with databases and
                            some
                            > of the advanced ideas in data representation, that it will avoid
                            integration
                            > problems going forward, then that should have some extra value to us. I
                            have
                            > been persuaded that, by this measure, the best way to represent a "null"
                            is
                            > to omit the element that would otherwise be present.
                            >
                            > By the way, the problem with "null" is not that it is not present in some
                            > programming languages, but rather that it is a single token with vastly
                            > overloaded meanings and ambiguous functional definition. Check the SQL
                            > literature or writings of Chris Date if you want extensive details.
                            >
                            >
                            > ----- Original Message -----
                            > From: "Dave Winer" <dave@...>
                            > To: <soapbuilders@yahoogroups.com>
                            > Sent: Sunday, April 01, 2001 8:37 PM
                            > Subject: Re: [soapbuilders] Re: Re-engaging
                            >
                            >
                            > >>What we can hope to do is to use a representation that allows us to
                            > transfer a programming-language "null" and that also is consistent with
                            the
                            > engineering disciplines that have given the most thought to the nulls
                            > problem, specifically semi-structured databases and directed-labeled graph
                            > data representations.
                            >
                            > I totally agree. I almost thought you said "transport" instead of
                            > "transfer". We can punt on the hard problem, and just accept a more modest
                            > challenge, to model the kinds of structures our languages like to push
                            > around. Null is a concept in many programming languages, I'm pretty sure
                            > there are languages that don't have such a concept. This is why it has
                            been
                            > problematic in XML-RPC-land, in fact the mail list is discussing this (for
                            > the 80th time) right now.
                            >
                            > That's why I wanted to get a token into the BDG that clearly says that if
                            > you have to move a null across the wire "this will work."
                            >
                            > Dave
                            >
                            >
                            >
                            >
                            >
                            > 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/
                            >
                            >
                            >
                            >
                            >
                            >
                            > 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/
                            >
                            >



                            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/
                          • mbalsara@yahoo.com
                            Andrew Ommiting the elements for null value, would pretty much require that RPC over SOAP must access parameter with names, instead of the order of parameters.
                            Message 13 of 13 , Apr 2, 2001
                            • 0 Attachment
                              Andrew

                              Ommiting the elements for null value, would pretty much require that
                              RPC over SOAP must access parameter with names, instead of the order
                              of parameters. Does the following text
                              (http://www.w3.org/TR/SOAP/#_Toc478383533), mean that the parameters
                              would be in order but could have some missing parameters for null
                              value or all the parameters would be in order including the null
                              values.

                              "Each [in] or [in/out] parameter is viewed as an accessor, with a
                              name corresponding to the name of the parameter and type
                              corresponding to the type of the parameter. These appear in the same
                              order as in the method signature."


                              Also, I am not sure how to interpret the following text for return
                              values, which indicates that the first accessor in response is a
                              return value.
                              "The method response is viewed as a single struct containing an
                              accessor for the return value and each [out] or [in/out] parameter.
                              The first accessor is the return value followed by the parameters in
                              the same order as in the method signature."

                              If the return value is null and hence the accessor missing, would it
                              break the above rule that the first accessor is return value?

                              manish


                              --- In soapbuilders@y..., "Andrew Layman" <yahoo@s...> wrote:
                              > There are a bunch of tokens that could be defined for "nulls". Per
                              the SOAP
                              > spec, any and all would be valid. Obviously, that is a problem for
                              > interoperability, so there is some motivation to agree on something
                              more
                              > specific. But more, we should have some motivation to agree on
                              something
                              > that does more than get us some interoperating applications this
                              week. If
                              > we can see that one choice will interoperate better with databases
                              and some
                              > of the advanced ideas in data representation, that it will avoid
                              integration
                              > problems going forward, then that should have some extra value to
                              us. I have
                              > been persuaded that, by this measure, the best way to represent
                              a "null" is
                              > to omit the element that would otherwise be present.
                              >
                              > By the way, the problem with "null" is not that it is not present
                              in some
                              > programming languages, but rather that it is a single token with
                              vastly
                              > overloaded meanings and ambiguous functional definition. Check the
                              SQL
                              > literature or writings of Chris Date if you want extensive details.
                              >
                              >
                              > ----- Original Message -----
                              > From: "Dave Winer" <dave@u...>
                              > To: <soapbuilders@y...>
                              > Sent: Sunday, April 01, 2001 8:37 PM
                              > Subject: Re: [soapbuilders] Re: Re-engaging
                              >
                              >
                              > >>What we can hope to do is to use a representation that allows us
                              to
                              > transfer a programming-language "null" and that also is consistent
                              with the
                              > engineering disciplines that have given the most thought to the
                              nulls
                              > problem, specifically semi-structured databases and directed-
                              labeled graph
                              > data representations.
                              >
                              > I totally agree. I almost thought you said "transport" instead of
                              > "transfer". We can punt on the hard problem, and just accept a more
                              modest
                              > challenge, to model the kinds of structures our languages like to
                              push
                              > around. Null is a concept in many programming languages, I'm pretty
                              sure
                              > there are languages that don't have such a concept. This is why it
                              has been
                              > problematic in XML-RPC-land, in fact the mail list is discussing
                              this (for
                              > the 80th time) right now.
                              >
                              > That's why I wanted to get a token into the BDG that clearly says
                              that if
                              > you have to move a null across the wire "this will work."
                              >
                              > Dave
                              >
                              >
                              >
                              >
                              >
                              > To unsubscribe from this group, send an email to:
                              > soapbuilders-unsubscribe@y...
                              >
                              >
                              >
                              > Your use of Yahoo! Groups is subject to
                              http://docs.yahoo.com/info/terms/
                            Your message has been successfully submitted and would be delivered to recipients shortly.