W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2011

Re: Classroom critique of XML Schema 1.1

From: Michael Kay <mike@saxonica.com>
Date: Sat, 19 Mar 2011 18:44:18 +0000
Message-ID: <4D84F982.4010907@saxonica.com>
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 

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 

Michael Kay
Received on Saturday, 19 March 2011 18:44:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:19 UTC