Whidbey XmlSerializer Bug Worth Understanding/Voting On

.NET XML API pundit, Daniel Cazzulino, has brought to light a bug in the way the Whidbey version of the XmlSerializer works with respect to fixed attribute values. If you used fixed values and expect them to be emmitted correctly to the instance document, I suggest you go vote this bug up.

That said, I think I understand why they don’t emit it. When you define a default value attribute in an XML Schema, it’s pretty much like saying: “If an instance document does not specify an explicit value for this attribute, this is the value that people interpreting the instance document should use instead.” Fixed is basically the same thing, except they can’t change the value at all. They can include it in the document, which is what Daniel is looking for here, but they cannot change the value. So, based on this logic, what the XmlSerializer is doing is saying: “Hey, this is the default/fixed value for the attribute, why should I pollute the instance document by stating the obvious when the person interpreting the document already knows what the value should be if I leave it out?”.


Ok, I somehow completely missed an important part of Daniel’s post so I need to correct myself. The part I missed is the all important use=”required” setting on the attribute that Daniel clearly pointed out in his post. How I missed it is beyond me, but obviously with that attribute in place the XmlSerializer is completely in the wrong for not outputting it. Thanks to Sam for pointing this out to me, I appreciate it.

0 thoughts on “Whidbey XmlSerializer Bug Worth Understanding/Voting On

  1. Surely this must be an error – if you read the bug carefully, the roundtrip fails on the validatation against the schema – because the attribute is marked are use=”required” but the serializer isn’t outputting it…


  2. Sam,

    Yes you’re right. I apologize. For some reason my brain skipped over the use=”required” when I was reading Daniel’s description. Thanks for the correction!


  3. Daniel,

    Yeah, but at this point there’s no getting it fixed until Whidbey. 🙂

    I checked the latest comments from MS and it’s interesting to see that the bug is going to be left in. Apparently the serialization implementation works exactly the way I assumed (it’s detecting that it’s the default and sparing the instance document the bloat). However, I don’t like their suggestion of commenting out the attribute in the wrapper class. If it’s a limitation of their serialization architecture they should just not output the DefaultAttribute at all from the tool in the default/fixed scenario.

Leave a Reply