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

935Re: Re-engaging

Expand Messages
  • yahoo@strongbrains.com
    Apr 1 5:58 PM
    • 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.
    • Show all 13 messages in this topic