- From: Michael Kay <mike@saxonica.com>
- Date: Sat, 19 Mar 2011 18:44:18 +0000
- To: "Costello, Roger L." <costello@mitre.org>
- CC: "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
> > 1. XML Schema 1.1 has a restriction that the XPath expression in an<assert> element can only "look down." It cannot reference items higher up in the XML tree, nor can it reference items in other XML documents. However, an attribute that is declared higher up in the XML tree can be referenced by the<assert> element if it is declared inheritable (inheritable="true"). During discussions it became apparent that inheritable attributes were created as an end-run around the restriction that the XPath expression in<assert> elements can't "look up." > > Recommendation: Lift the restriction that the XPath expression in<assert> elements can only "look down." Permit the XPath expression to look anywhere, including to other XML documents. First, the general principle is that the type of A constrains the contents of A, not the context in which A can appear. Lifting this restriction would allow assertions like <publisher/> is a valid element only if it appears within a document that has "book" as its outermost element. There are many good reasons for disallowing such assertions: (a) it's not an assertion about publishers, it's an assertion about the documents they appear in. This is the wrong place to make such an assertion. (b) if such assertions were allowed, the schema processor would have to hold the entire document in memory, even if such assertions are never used. (c) many of the specifications that rely on XSD for their type system (for example XQuery and XPath) assume that if an element E is a valid instance of type T, then when you copy E, the copy will also be a valid instance of T. It's true that inheritable attributes appear to compromise this principle. You've overlooked, however, that inheritable attributes can't be referenced in assertions, only in the expressions that affect conditional type assignment, which limits the damage. I can't say I think the mechanism of inheritable attributes is perfect, but it solves a problem. > 2. The attributes identified by defaultAttributes only applies to that schema file, not to imported or included schema files. That rule seems reasonable for imported schema files but not for included schema files. You only argument here is that it "seems reasonable". I don't see why. xs:schema has a number of attributes that define defaults for declarations appearing textually within that xs:schema element. This seems a simple and understandable rule, and I can't see why defaultAttributes should be any different. > > 3. If an element has multiple inheritable attributes in its ancestors and they have the same name, only the closest one will be visible to the element. For example, suppose the<Comment> element has two xml:lang attributes (both inheritable) that are ancestors: > > <Document xml:lang="FR"> > <Chapter> > <Section xml:lang="EN"> > <Comment> > > An XPath expression in an<assert> element on<Comment> can only use the closest xml:lang attribute (xml:lang="EN"). It cannot use the xml:lang attribute that is higher up (xml:lang="FR"). > > The semantics of xml:lang are that only the innermost xml:lang applies to an element. We generalized the rules to other attributes with similar properties: but the essence of such attributes is that the one that matters is the innermost one, and that's why they work the way they do. XSD 1.1 has been ten years in the making, and everyone is getting impatient for the process to be finished. It's true that it's only when implementations start to appear that some of the usability issues in a spec start to become apparent. But I'm afraid if we go back to the drawing board on fundamental design choices like these - all of which have been extensively debated - the chance of ever getting finished are zero. Michael Kay Saxonica
Received on Saturday, 19 March 2011 18:44:49 UTC