i think i am well-aware of the better features of SA and i did not want to say that they do not matter. they absolutely do. but the more fundamental problem is that even though XSD has some uptake because a lot of tools spit out XSDs, in many cases these XSDs are not really treated as application data models, and thus they actually make little sense as a programming type system for XSLT. i think if it were possible (which it is not, i think) to investigate (a) how many users are using XML without or with XSD, and more importantly, (b) of those XSD users, which of those generate XSDs from other models and never look at it again, and who actually models and treats XSD as the application data model (and thus wants good support in the programming language), this last category of "real XSD users" is actually quite small. don't get me wrong, i think it is a very good idea to have XML models for what you're doing; but it is very hard to get people to start thinking in XML-centric ways rather than whatever their programming environment gives them as the main abstraction. and then there is this whole snake pit of how to actually design "good XSD", if you're commited to do it. there is little literature and little support for that, and more importantly, the real important questions of extensibility and versioning and mostly left to the XSD designer. and they're easy to get wrong. if XSD and XSLT had good and built-in language features for dealing with extensibility and versioning, this could actually be the killer argument for why people want XSLT-SA and are willing to pay for it, there would be immediate and visible benefits in terms of robustness and product lifetime.