And a more general version of your question: is a filter technology that reads in resources (with a standard representation from a location using a URL) but does not write out to a representation that can be potentially located with a URL) really a "web" technology?
In the case of XSLT, it does and so is, for its main input and output.
But with validator standards, none apart from Schematron SVRL do, and I suggest they should not be categorized as Web technologies. (And the same goes for XML DTDs for validation, but not attribute-value implication.) In the case of XSD, it is compounded that the PSVI has no serialized form at all: so not only is the output of validation errors not available as a resource with a concrete standard representation, the PSVI elements that have been successfully validated are not available either.
The consequence: if the both the input and output for a filter are not available with concrete representations that could be at a URL, then the output requires some extra technology or platform to access and process. So you end up with absurdity of people buying into XML to get loose coupling and distributability, and then finding that XSD PSVI forces you to have tight coupling and large-object sharing. I think this is a real problem for client/server architecture with XQuery with XSD, because you must throw out the non-XML PSVI information when you send the query results from the server to the client. That cannot help but to drive people to use JSON.
