[xsde-users] XSD/e and xsi:nil support?

[Witek Piet]

Hi Boris,

Thank you very much for your quick answer. It sounds as if nillable elements
is not the approach to follow ... . ;-)

Basically we want to define in XSD a config data struture, e.g.:
<complexType name="config">
  <sequence>
    <element name="sampling_enable" type="boolean" minOccurs="0"></element>
    <element name="sampling_rate" type="unsignedShort"
minOccurs="0"</element>
    ...
  </sequence>
</complexType>

<element name="config" type="config"/>

We want to be able to set/get elements of this data structure using the tags
of the complexType-definition. We have defined three primitives:
 *) set: client -> data manager: set an element
 *) get: client -> data manager: get an element
 *) response: data manager -> client: answer to get

'set', 'get' and 'response' would look like this (I have left out the
XSD-definition for these):
<set>
  <config>
    <sampling_enable>true</sampling_enable>
  </config>
</set>

<get>
  <config>
    <sampling_enable></sampling_enable>
  </config>
</get>

<response>
  <config>
    <sampling_enable>true</sampling_enable>
  </config>
</get>

'set' and 'response' would work fine using the definition of config, but
'get' would not work as it does not contain a value. We would rather avoid
sending a 'dummy' value in 'get'. As I see it the only solution to this, if
nillable is not possible, is to define an enum (or similar) describing the
elements of config. This would be used in 'get' to specify which elements of
config are requested. Do you agree on that?

Once again, thank you very much for your help.

Best regards,
Witek


On Mon, Feb 7, 2011 at 6:30 PM, Boris Kolpackov <boris at codesynthesis.com>wrote:

> Hi Witek,
>
> Witek Piet <travelwitek at gmail.com> writes:
>
> > I have read in the XSD support list, that XSD does not support nillable
> and
> > xsi:nil. Based on my tests I assume that this (nillable and xsi:nil) is
> not
> > supported by XSD/e either.
>
> That's correct.
>
>
> > If not are there any plans on implementing this feature in future
> releases
> > of XSD and XSD/e?
>
> No, not at the moment. This is one of those XML Schema "mis-features" that
> doesn't make much sense, doesn't map cleanly to object-oriented models,
> and,
> as a result, hardly used by anybody.
>
> The main problem with the nillable elements in XML Schema is the fact that
> an element declared nil can still have a full set of attributes. Consider,
> for example:
>
>  <complexType name="person">
>    <sequence>
>      <element name="first-name" type="string"/>
>      <element name="last-name" type="string"/>
>    </sequence>
>    <element name="id" type="unsignedLong"/>
>    <element name="email" type="string"/>
>  </complexType>
>
>  <element name="person" type="person" nillable="true"/>
>
> Then in your XML document you can have:
>
>  <person xsi:nil="true"/>
>
> Which makes sense. But then you can also have this:
>
>  <person xsi:nil="true" id="123" email="null at null.com"/>
>
> Which doesn't make much sense. In a sense, this means that only half of the
> object is NULL. There is no way in programming languages such as C++ to
> have
> pointer or object that is "half NULL".
>
>
> > Does XSD and XSD/e support any other mechanism for assigning a null
> > value to an element? If this is the case could you please give me a
> > hint?
>
> The cleanest and most straightforward way is simply to declare an element
> optional by setting its minOccurs="0". For example:
>
>  <complexType name="bank_account">
>    <sequence>
>      <element name="primary_holder" type="person"/>
>      <element name="secondary_holder" type="person" minOccurs="0"/>
>    </sequence>
>  </complexType>
>
> Here we have a bank account type which must have a primary account holder.
> It also may or may not have the secondary holder. For example:
>
>  <bank_account>
>    <primary_holder/>
>      ...
>    </primary_holder>
>  </bank_account>
>
>  <bank_account>
>    <primary_holder/>
>      ...
>    </primary_holder>
>
>    <secondary_holder/>
>      ...
>    </secondary_holder>
>  </bank_account>
>
> In the C++/Hybrid object mode you will check whether secondary holder
> is set like this:
>
> bank_account& acc = ...
>
> if (acc.secondary_holder_present ())
> {
>  person& sh (acc.secondary_holder ());
>  ...
> }
>
> Which, in a way, is similar to checking whether a pointer is NULL.
>
> Boris
>