How to handle making everything optional
by Rick Jelliffe
Glad to see this, because it gets us to the start of where Schematron is useful: if the XSD schema just expresses only the most invariant of the invariants of the schema, then what do we use to express the constraints appropriate in t particular phases of a document't life or history or evolution? The "contract" is just one kind of phase.
There was some debate (Roger Costello was a champion) of default openness in XSD. But I have seen increasing use of the idea that the master/base schema has to be as loose as possible: indeed, derivation by restriction is fragile and impractical without it, because if you need a derived schema to have something optional you need to go back to the master to make it optional. A friend reports that he has taken to calling super-loose base schemas "vocabularies" and "ontologies" to avoid confusing people who expect a schema to be really prescriptive.
If the schema designer gets the user cases and they disagree in the details or only describe a set of loosely defined terms that share some semantics, there is little choice but to make the schema accept the variation. One asks how to quantify the looseness of a concept lattice. At what point does a prescription only say "object" or "thing", and the answer to that question is why XML is 'just a syntax', or minimal contract.