Tom, I had a quick look at your source collection,
and especially from
http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/default.aspx I believe that I better understand your scenario now. It is what I have been referring to the ambiguity of xml and the ambiguity/heterogeneity of xml handling (parsing, serialisation) in a previous posting.
However, this is more related to the layer of marshaling/demarshaling than others, higher layers such
as type bindings (stream -> language type), invocation
dispatch etc. That's what the authors of the
article and the described extension mention themselves.
The reason for this behavior has to do with XmlSerializer, the underlying plumbing that takes care of object deserialization. XmlSerializer is very forgiving by design. It happily ignores XML nodes that it didn't expect and will use default CLR values for expected but missing XML nodes. It doesn't perform XML Schema validation and the consequence is that details like structure, ordering, occurrence constraints, or simple type restrictions are not enforced during deserialization.
This is an implementational issue and not one that was designed or forgotten as feature. Why, because in a final stage (whether the value parsed for CalcArea->{W|w}idth correctly or not) will be tried to be assigned to the double-typed attribute of an object CalcArea . And this can fail or it won't.
But there are more drastic examples as the lower/major case example if we talk about XML marshaling: What about either streaming based on XML attributes or XML elements. Semantically equivalent (or at least, undecided), but syntactically completely different.
There is certainly a role for strict schema validation in terms of XMl Schema, RelaxNG etc., but not necessarily for examples as those given above.
I would go for a double strategy (in fact, this is what I started for MY fetish):
- provide an extension mechanism (interceptors) that can hook in schema-based validation on various scopes. But then it is also schema validation to the developer, i.e. he has to provide a schema fragment to be used as validation rule. See e.g. http://www.sosnoski.com/jibx-wiki/space/axis2-jibx/validation. I don't think that providing validation rules as language extension or annotation elements to the language are appropriate here, simply introducing a new complexity and still requiring basic knowledge/anticipation of schema validation.
- Provide validating message parser. To a certain level but not complete level of complexity, these problems (cases, attribute vs. element) can be handled at this level.
- Validating type binding procedure: When parsed message elements become elements of object states, than provide some validation and conformence checks. Oh, wait, this would require some OO! Indeed, OO principles are quite handy here. XOTcl comes with some nice, extensible mechansim to provide these functionalities.
