W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2007

When xsi:type doesn't resolve

From: Michael Kay <mike@saxonica.com>
Date: Sun, 14 Oct 2007 17:22:41 +0100
To: <xmlschema-dev@w3.org>
Message-ID: <00b501c80e7e$71b7d3c0$6501a8c0@turtle>

A Saxon user has raised this query at

https://sourceforge.net/forum/message.php?msg_id=4567871

and I'm struggling how to interpret the spec in this area. Perhaps someone
can shed some light.

The relevant content is

<env:Body> 
<foo:person xmlns:foo="http://foo" xsi:type="foo:driver"/> 
</env:Body> 

where 

(a) the content model for env:Body is

<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"
processContents="lax"/> 

(b) the schema contains no type declaration named foo:driver

After struggling with the 1.0 rules, I've turned to the 1.1 spec which in
this area (as far as I can tell) attempts to clarify the rules without
materially changing them.

Let's start with Schema-Validity Assessment (Element) as applied to the
env:Body element. Clause 1 is true; Clause 2 is trivially true because there
are no attributes; so we invoke clause 3. 

Clause 3.1 says "If the chld has a .governing element declaration. or a
.governing type definition.... From the definition of "instance-specified
type definition", it seems that the child has neither. Therefore clause 3.3
is invoked: the child is laxly assessed with respect to xs:anyType.

"Laxly assessed" invokes Element Locally Valid (Type) with respect to
xs:anyType, clause 4 of which says that if there is an xsi:type attribute
then it must resolve to "the type definition" (that is, xs:anyType). It
doesn't; therefore the element is not locally valid with respect to the type
xs:anyType.

But my problem then is with the introduction to clause 3 of Schema-Validity
Assessment (Element), which says "3 the appropriate case among the following
is true... 3.3 its schema-validity is laxly-assessed." Well, we've done lax
assessment, and we found the element to be not locally valid, so is 3.3 true
or false? Intuition says that it's false, and therefore the env:Body is
invalid. But is my intuition right?

It also seems a little odd that clause 3.1 should treat a non-resolving
xsi:type attribute as being simply ignored, while 3.3 treats it as causing
invalidity. Is this really intended, or is it just an accident of the way
the rules are written?

If we go back to the 1.0 version of Schema-Validity Assessment (Element), it
leaves far more holes, because it invokes validity assessment on the
children without stipulating exactly how it is done. I can't actually find a
chain of reasoning in the 1.0 spec that invokes xsi:type at all when
elements are validated against wildcards, but it surely can't be right that
it's ignored. Schema-Validity Assessment (Element) has the same property as
the 1.1 rule, that a non-resolving xsi:type attribute is simply treated as
if it weren't there. However, Element Locally Valid (Type) in 1.0 does *not*
have the clause 4 that requires xsi:type to resolve to the type against
which you are validating.

One feels that the bottom line ought to be an outcome of "validity not
known", but it's hard to see how to get there.

Michael Kay
http://www.saxonica.com/
Received on Sunday, 14 October 2007 16:22:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:15:00 GMT