- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Mon, 27 Apr 2009 10:51:36 -0600
- To: "Costello, Roger L." <costello@mitre.org>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
On 27 Apr 2009, at 10:03 , Costello, Roger L. wrote: > >> Making the 'available documents' property be the empty set helps >> ensure (a) better interoperability between validators, and (b) the >> context-independence of schema-validity assessment of an element >> or attribute against a declaration or type definition. The >> context-independence of validation against a type is important to >> many users of XSD (although not, I suspect, to all). > > I'm not clear on (b) but (a) certainly sounds like the decision to > disallow doc() for cross-document validation was done to make it > easier to implement 1.1 schema validators. Validators are built > once, but used many times. Disallowing doc() seems to sacrifice XSD > 1.1 usability in favor of ease of validator implementations. Er, not necessarily, no. Ensuring better interoperability is not the same as ensuring easier implementability (although they are also connected). XPath 2.0 says the set of available documents is to be "initialized by mechanisms defined by the host language". In XSLT 2.0 and XQuery 1.0, it is implementation-defined what documents are available. (Actually, I'm not entirely clear whether in XQuery it's implementation-defined or implementation-dependent -- but it's certainly not defined by the spec.) XSD 1.1 thus faces the choice: - Define a fixed non-empty value for 'available documents'? (How? What documents should be included?) - Make the set implementation-defined? (So your proposed assertion would make country code 'France' valid in one processor, which included 'countries.xml' in its set of available documents, and make it invalid in a different processor which chose to make 'available documents' the empty set. Having different processors produce different validation results for the same inputs is something some people would incline to regard as an interoperability problem. - Specify that the set is empty. If ease of implementation were the main criterion, I think the WG might have chosen to make the property implementation-defined; that way an XSD implementor could use an off-the-shelf XPath 2.0 implementation and let it do whatever it wanted to do about the 'available documents' property. Different people may well prefer different tradeoffs here. Those in the WG who might have preferred that the available documents component of the dynamic context be implementation-defined will have seen, if they had eyes to see, that others in the WG would be adamantly opposed to that decision. Which would they rather have? Assertions without implementation-defined 'available documents'? Or no assertions at all? From the presence of assertions in the spec in their current form, you can infer the choice those members of the WG made on that question. As I've illustrated in other mail this morning, I don't think XSD's decision in this area actually prevents anyone from checking the values of 'country' elements in one document against the values of 'country' elements in another document; it just means they won't do it via an assertion. So the usability of the spec in actual situations does not seem to me to take too big a hit from this particular decision. So it says here that it's better to have assertions in their current form than no assertions at all. YMMV. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Monday, 27 April 2009 16:52:16 UTC