RE: Conditional Levels of a Schema

> It is A, and Michael and Steve's as well as some of your 
> ideas are exactly to the point. We would like to keep one 
> master document that is the most liberal and has only the 
> minimal set as required items; and separate derived ones; 
> there are a few more variants than those mentioned here, most 
> of them "nested" to form a stack of requirements (the patient 
> case is the only non-nested).
> 
> The idea is that hospital administrators can put up a filter 
> allowing only anonymized files out. Or that researcher who 
> want calibrations information that is not relevant for others 
> can check with their special version of the schema if all 
> required items are there. 
> 
> While Michael's $param idea looked easiest for me at first, I 
> think Steve has made a good point and that his way is 
> preferred because is ensures that the master document is always valid.
> 

I've actually been experimenting with ideas that take the "conditional type
assignment" facility in XSD 1.1 and extend it by allowing access to "schema
parameters" which must be set when starting a validation episode (the
current facility can only be driven by data that appears in the instance
document, not by external data supplied at validation time). This approach
seems to offer a very good fit to your use case (which I think is not at all
uncommon). Unfortunately the schema specs move slowly.

Michael Kay
http://www.saxonica.com/