- Apr 1 5:58 PMHello. 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
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
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
- << Previous post in topic Next post in topic >>