- Apr 1, 2001All 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
For example, given a structure of value like
new Foo("a", null, "c")
I recommend a serialization of form like
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:
> Is <nil xsi:null="1"/> OK with you as a way of representing nil or
> whatever in SOAP 1.1 as of 4/1/01?
> If not, what do you think is the right way to represent nothingness
> voidness or emptyness?
> ----- 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
> > here, and, since I am not yet caught up, I will sometimes lack
> > of the context of a posting or will comment on something in
> > of many subsequent comments. If you can tolerate that, thank you.
> > Glen Daniels wrote "Re: null params in the BDG - I haven't seen
> > 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 -
> > <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
> > the W3C XML Schemas specification, March 2001, no longer contains
> > attribute of that name. This puts its use on pretty thin ice
> > forward.
> > There is a similar attribute, now called "nil", described by the
> > Schemas specification. It was renamed specifically to disclaim
> > definite relation to the idea of "null" in a programming language
> > 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
> > specification, which says, roughly, that a "null" (whatever a null
> > is) may be represented by (a) omission of the element that would
> > represented a value, (b) presence of the element that would have
> > contained a value, but now bearing an xsi:null='1' attribute, or
> > any other signal that is agreed on by the communicating
> > 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
> > of programming language structures. Where the difference matters
> > 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
> > The RDF Activity at W3C is also an example of a domain in which
> > 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
> > with databases and RDF as well as with traditional programming
> > languages, I favor consistently representing a null by omitting
> > corresponding element.
> > To unsubscribe from this group, send an email to:
> > soapbuilders-unsubscribe@y...
> > Your use of Yahoo! Groups is subject to
- << Previous post in topic Next post in topic >>