On 6 Oct 2009, at 14:45 , Kevin Braun wrote:

> Hello,
>
>
> Can anyone explain the following comment from the "changes since" in  
> XSD 1.1?
>
> "When an |xsi:type| attribute appears on an element, and has a QName  
> as its value, but the QName does not resolve to a known type  
> definition, processors are now required to "fall back" to lax  
> validation, using the declared {type <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition 
> >
> definition} <http://www.w3.org/TR/xmlschema11-1/#ed-type_definition>  
> of the ·governing element declaration· <http://www.w3.org/TR/xmlschema11-1/#key-governing-ed 
> > as the ·governing type definition· <http://www.w3.org/TR/xmlschema11-1/#key-governing-type-elem 
> >."
>
>
>
> First, I believe that lax validation is by definition against  
> xs:anyType, so I'm not sure what it means to do lax validation using  
> some other type.

You're right; the description should not use the term 'lax
validation'.  The new rule is an attempt to define more
useful fallback behavior than fallback to lax validation.

>
> Second, such a case as is being described violates rule 4 of Element  
> Locally Valid (Element) (§3.3.4.3) <http://www.w3.org/TR/xmlschema11-1/#cvc-elt 
> > (the instance-specified type definition would be absent),

Correct.  So the element is not marked valid.

> and I don't see where there is any exception made to it.  There is  
> some verbiage (in §3.3.4.3) about what happens to the governing type  
> declaration in this case, but I don't think this verbiage is giving  
> an exception to rule 4 (I assume it is summarizing the application  
> of the definition of "governing type declaration").

Clause 5 of the validation rule says that the element is to be validated
against its governing type definition.  This doesn't constitute an
exception to clause 4.  Validating the element against the declared
type, rather than xsd:anyType, can be helpful when the downstream  
processor
wishes to recover from the missing component and when the declared type
has some local element declarations which would not be found by  
validating
the element against xsd:anyType.


> Schema-Validity Assessment (Element) (§3.3.4.6) <http://www.w3.org/TR/xmlschema11-1/#cvc-assess-elt 
> > does give a requirement for lax assessment according to  
> xs:anyType, but I don't think it applies here because the situation  
> described doesn't prevent assessment - it just has "invalid" as the  
> outcome.  Besides that, the type to use for the lax assessment  
> doesn't agree with the statement I quoted.
>
> So, in short, I don't know what to make of the above statement.

I hope the comments above help clarify things.

>  Can anyone point me to where the "fall back" requirement can be  
> found?


I'm not sure whether you mean "what user requirement does this
serve?" (answer:  better behavior in the case of missing
components), or "why does the change list say that the
processor falls back to the declared type?" (answer:  because
clause 5 of Element Locally Valid (Element) says to validate
the element against its governing type definition, and the
definition of governing type definition says that if the
instance-specified type does not successfully override the
selected or declared type [which will be the case if the
value of the xsi:type attribute fails to resolve], then the
element's declared type will be the governing type).

HTH

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************