Re: Fall back for missing xsi:type?

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
>

Received on Thursday, 8 October 2009 13:27:01 UTC