[xsd-users] Default values for optional elements.

[Moss, David R (SELEX Comms) (UK Christchurch)]

Boris,

That's great news, thanks.

A further thought I had was, having generated these default values, to
exclude these elements when serializing the data to file again. i.e. an
xml file containing unspecified elements would look the same before and
after serialisation.

The only slight issue with this is that if a value was set in memory at
runtime, overriding the default, then that value would obviously need to
be serialized.


Cheers,
Dave.

Dave Moss
SELEX Communications
Grange Road
Christchurch
Dorset  BH23 4JE
United Kingdom
Tel: + 44 (0) 1202 404841
Email: david.r.moss at seleniacomm.com


-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com]
Sent: 03 February 2006 14:47
To: Moss, David R (SELEX Comms) (UK Christchurch)
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] Default values for optional elements.

David,

Moss, David R (SELEX Comms) (UK Christchurch)
<david.r.moss at selex-comm.com> writes:

> I have a large schema that contains a lot of optional elements with
> default values specified. In code, when a query is made as to the
value
> of one of these elements, I'm providing a hard-coded default (the same
> value as specified in the xsd file) for cases where the element wasn't
> present:
>
> const myData_t wrapper::getData() const
> {
> 	if( m_parent.myData().present() )
> 	{
> 		return m_parent.myData().get();
> 	}
> 	else
> 	{
> 		return someDefaultValue;
> 	}
> }
>
> This is clearly a maintenance nightmare! It also seems a bit backward
as
> a default is already specified in the xsd file.

Well, that's the way XML Schema spec prescribes handling of elements
with
default values. In particular, for elements (unlike attributes), there
are
three cases to consider:

1. Value specified in the instance - that value is used.

2. Empty value is specified - default value is used.

3. No element specified - element not present.

The following table in the manual summarizes all the cases:

http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#A


The reason why XML Schema specifies it this way is probably because
element's name (in case of substitution groups) or the xsi:type
attribute carries type information.


> Is it possible to get the generated code to provide the default i.e.
an
> optional xsd flag that meant get() would return a default value if the
> optional element wasn't present:
>
> ...
>
> Any thoughts or alternatives greatly appreciated (I don't want to use
> attributes instead of elements).

At the moment I don't see any reasons why such an option couldn't
be supported. Except that, as for attributes, when this option is
specified, optional elements with default/fixed values would be
treated as belonging to the One cardinality class because their
values will always be present (so no need to call .get ()).

I will try to implement it in the next version or two (2.0.0
or 2.0.1).


hth,
-boris


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codesynthesis.com/pipermail/xsd-users/attachments/20060206/5469f524/attachment.html