Attempting to address Rajesh's concerns about optionality...

My last post on optional content triggered a conversation between Rajesh and Jon. Rajesh's main concern is that making almost everything in your schema optional may give you flexibility, but if occurence requirements aren't captured somewhere, then its hard to consume a service (or other XML). That's true - you need to know what's required. The problem is that if you put that info in your schema, and then you need to change it and that requires changing your namespace, then you have a problem. I can see two possible solutions. One is to include occurence info in your schema but make it clear to everyone that you feel free to change it without changing your target namespace. The big issue here is that if you have an XSD used by multiple services that have different occurence constraints, what do you do? You could combine all the requirements and express the weakest, but keeping that up to date over time would be hard. You could have two different copies of the schema, each with different occurence requirements, but then how does the consumer generate code from both in a meaningful way? You could solve this problem by using a common schema with everything optional, and then offering a per-service redefinition of the schema with specific occurence constraints. xsd:redefine would handle that nicely, but you need the tools to know that they're supposed to generate code from the core schema referenced by the redefine. Since none of the mainstream code-gen tools handle redefine, that seems like a dead-end (which is too bad because it *does* capture the semantics nicely). No, I still think you're better off focusing your schema on describing the shape of data, if it is present, and captureing the current rules for what must be present some other way, e.g., documentation. Increasingly, I think of this as a sort of hybrid of static and dynamic typing. At development time, you get enough info to statically compile your code and not be way off base (as you could be with Process(string xml)). But the system is dynamic enough to allow wiggle-room at run-time to compensate for service evolution.