Firstly, the Xml Schema spec does specify the parsing of an optional attribute with a default value: if such an attribute is absent in an xml document, then when parsed with the XSD, they appear to be present, and having that default value.
Secondly, some tools apply this idea to serialization, so that attributes with default values are omitted (in other words: given an optional attribute with a default value, when an attribute has that value, it is omitted).
However, as far as I can tell, this serialization behaviour is not specified in the Xml Schema. But it’s a complex spec, and maybe I missed it – does the spec define serialization of optional attribute with a default value?
If not, maybe it has become a de facto standard – do many tools implement this behaviour? I’ve seen that Microsoft and MarkLogic do it:
- C# XML Serialization of the default values of optional attributes
- “.net” (in general?) Including xml attribute when the value is the same as the default
- marklogic Default Schema Values in MarkLogic
But not JAXB:
- not JAXB JAXB Avoid saving default values
Finally, – and perhaps here I teeter on the precipice of subjectivity – what should be the behaviour?
Omitting attributes with default values reduces clutter, especially if the default value is expected and common. e.g. minOccurs and maxOccurs default to 1 in an XSD itself – if you’ve been processing an XSD, and then serialize the result, having them suddenly appear on every <element>, <sequence>, <choice> etc makes it less readable.
OTOH, in objects and data structures, if there is a default value, we expect it to be there if we look at it. Therefore, it can be surprising when an attribute that has a default value is omitted – as the above SO questions show.
I think it might depend on whether you consider the result to be data, or a representation of data. With a representation, it can be very convenient to modify it to make it more readable. But with data, you expect it to exactly be the data. Thoughts?
For the first question, the answer is NO – it is not something the XSD spec is concerned about.
2nd, it is kind of hard to get an answer from a single person, simply because there are so many toolkits doing this sort of thing… what constitutes “many”, which are to be considered relevant, etc.
3rd… In my work I (used to) bump quite often into the recommendation of NOT using defaults in XSDs. The argument was that defaults restrict the correct use of an XML instance by imposing the use of an XSD-aware processor OR forcing additional logic/settings in the consumer application. And, let’s not forget those people that consider defaults as evil – the source of hard-to-find bugs, e.g. configuration items in test/production environments.
That being said, to me a tool serializing defaults is a good indication of employing a “defensive programming” style; it promotes the interoperability of XML irrespective of a schema language.
So, I believe that any serious XSD-aware XML serializer SHOULD provide an option to enable/disable the serialization of default values. I would set the default to ON (serialize).
Where you have specialized processors that by design are bound to understand and comply with a language as defined by XSD, then indeed default values on the wire may be perceived as clutter (your min/max occurrence reference); having the option to turn off these values should help there.