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

944Re: [soapbuilders] Re: Re-engaging

Expand Messages
  • Paul Kulchenko
    Apr 1, 2001
      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
    • Show all 13 messages in this topic