Re: Supporting incremental-definition of a type?

 >We will try this approach and see how it works out. I think it brings 
up some change management questions as the definition of Student evolves 
over time, which would impact the subtype-based messages...

Yes, this is a serious problem with the xs:restriction mechanism for 
defining subtypes, that you have to declare all the parts of the content 
model that you want to leave unchanged, rather than the parts you are 
restricting away. Restriction by assertion in XSD 1.1 is one way around 
this; it also allows the restrictions to penetrate deep into the 
hierarchy rather than requiring new restricted types at every level (for 
example to define that in a financial transaction, all money amounts 
must be in US dollars, you only need one assertion at the top level, 
rather than defining restricted types all the way down).

(There's an unfortunate usability glitch in XSD 1.1 which we noticed too 
late to fix it, that when you restrict by assertion you still need to 
repeat the entire content model. But you can get around this if you use 
named model groups. In fact careful use of named model groups is 
generally a good idea whenever you are planning to use restriction of 
complex content.)

Michael Kay
Saxonica

Received on Monday, 18 June 2012 15:21:39 UTC