Fall back for missing xsi:type?

[Kevin Braun]

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.

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), 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").

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.  Can
anyone point me to where the "fall back" requirement can be found?

Thanks,

--
Kevin Braun
Objective Systems, Inc.
http://www.obj-sys.com

[C. M. Sperberg-McQueen-2]

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
****************************************************************

[Kevin Braun]

Excellent, thanks!

On 10/6/2009 6:40 PM, C. M. Sperberg-McQueen wrote:

>
> 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
>