Re: NEW ISSUE: xs:default handling by generated types

Agree to everything you said. To expand on it a little bit...

Many people may have misunderstood the meaning of element defaults. They 
are *not* default element values; they are default element *content* 
values. (Elements may have attributes, which are not affected by element 
defaults.)

So in terms of serialization, the decision should be made in 2 steps:
- (Ignoring whether the element has default or not) whether an element 
should be serialized
- If yes, then look at the default and decide whether the default should 
be used

Similarly for xsi:nil (which people also tend to misunderstand), it 
applies to element content too (as opposed to element itself). When 
xsi:nil is true, the element still has a value: all its attributes plus 
its content (which happens to have nil value).

Thanks,
Sandy Gao
XML Parser Development, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com


public-xsd-databinding-request@w3.org wrote on 01/24/2006 09:40:11 AM:

> * Title:          xs:default handling by generated types
> * Description:    see below
> * Target:         "Basic"?
> * Proposal:       see below
> This is a specific problem with xs:default and type 
> generators/serializers that can potentially be merged with ISSUE-7 
> (minOccurs=?0? and nillable=?true?). 
> The xs:default attribute on an element declaration is a feature of 
> XML Schema that is meant to be applied by a schema validation 
> process.  Default values are inserted into the post-schema-
> validated-Infoset (PSVI) *only* if the element is present in the 
> input document with empty content (and without an xsi:nil=?true? 
> attribute).  By now, virtually all schema validation tools execute 
> this rule correctly.  However, many type generators, including .NET 
> 2.0*, assign default values when de-serializing a message where the 
> element defined with a default value is missing.
> This has implications both when a developer sends a message with a 
> payload serialized from a generated type and when a message is 
> received / de-serialized.  On the way out, the developer needs to 
> distinguish between a NULL value, a ?left-unsaid? value, and an 
> explicit ?use the default? value (since the message *has* to contain
> an empty element for the default value to be injected).  This 
> outbound issue overlaps a great deal with ISSUE-7.  On the inbound 
> case, some type serialization tools inject the default value even 
> when the element is absent from the message.  This is probably a 
> side-effect of having the default value assigned in the class 
constructor. 
> 
> Example:  Given this schema and message content:
> <xs:element name="NewAccount">
>       <xs:complexType>
>             <xs:sequence>
>                   <xs:element name="Name" type="xs:string"/>
>                   <xs:element name="CreditLimit" default="1000" 
minOccurs="0"
> type="xs:decimal" />
>             </xs:sequence>
>       </xs:complexType>
> </xs:element>
> 
>  <t:NewAccount xmlns:t="urn:epic:schematest1">
>       <t:Name>MegaCorp</t:Name>
> </t:NewAccount>
> A PSVI emitted from a schema validation tool will correctly NOT 
> contain a ?CreditLimit? node because that element MUST appear in the
> received XML document with empty content.  But an instance X of the 
> type-generated class NewAccount will have member values assigned like 
this: 
> X.Name=?MegaCorp?, X.CreditLimit=1000.00, which is incorrect.
> 
> Solution: Type de-serializers should not apply default values unless
> the XML payload has the relevant element present with empty content.
> Generated types MAY apply default values to new class instance 
> members.  Generated types SHOULD provide an explicit mechanism for 
> developers to serialize a class member as an empty element with the 
> intention that the receiver will inject default values in a PSVI.
> 
> Thanks,
> Erik Johnson
> Epicor Software Corp.
> * I am awash in .NET projects at the moment, so it?s the first place
> I go to look for issues!