This project is read-only.

where have support for xsd:choice gone?

Dec 19, 2012 at 6:47 PM

In schema i have

<xs:complexType name="tPlanKey">
 <xs:choice>
  <xs:element name="id" type="xs:int"/>
  <xs:element name="projectname" type="xs:string"/>
 </xs:choice>
</xs:complexType>


which is generated to

public partial class TPlanKey
{

    private object itemField;

    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute("id", typeof(int))]
    [System.Xml.Serialization.XmlElementAttribute("projectname", typeof(string))]
    public object Item
    {
        get
        {
            return this.itemField;
        }
        set
        {
            this.itemField = value;
        }
    }
}
which is really bad, cause I have to get the type to find out which was specified in request.

I remember there was ItemChoiceType-enum before. I'm baffled.
Dec 19, 2012 at 6:56 PM

It seems that if I add fake values to it I get the ItemChoiceType. That is weird. Is it a bug or is there a logic behind it?

Dec 20, 2012 at 1:00 AM

That decision is made by .NET Framework code and not WSCF.blue. It is hard to know what the original thinking behind some of these design decisions was.

I generally stick the most simplistic types that I can get away with when creating my own contracts. For example, you could just use a sequence with an Id element for the value and an IdType element to indicate which form of identifier is provided. You would then validate the Id value based on the IdType.

<xs:complexType name="tPlanKey">
 <xs:sequence>
  <xs:element name="Id" type="xs:string"/>
  <xs:element name="IdType" type="tIdType"/>
 </xs:sequence>
</xs:complexType>

When you have to implement a third party contract with things like this you just have to deal with the weirdness the best you can, and encourage them to simplify their contract in the future.