Re: 1.0 errata section 10 (complex type validation clarification) (PR#135)

Steve,

please see comments inline.

> Leigh,
> 
> Thanks for the quick and thorough reply, I have responded inline.
> 
> Thanks,
> Steve Speicher
> 
> "Klotz, Leigh" <Leigh.Klotz@xerox.com> wrote on 03/28/2007 01:49:42 PM:
> 
>> Steve,
>> We discussed this issue at today's teleconference and have some
>> observations and questions.
>> We believe that xsi:type cannot be used to contradict an
>> xf:model/@schema or xf:model/xsd:schema declaration, only to refine it
>> under rules specified normatively by XML Schema.
>> If you agree with this statement but think our wording conveys
>> otherwise, please read point 1.
>> If you believe that XForms can or should allow xsi:type to contradict an
>> author-specified schema, please read points 2, 3, and 4.
>> 1. We agree with you in general that "the wording is intended to state
>> that the node is valid if it passes valdation for both 1) External or
>> inline schema as possibly redefined by xsi:type 2) type MIP." However,
>> we don't agree that about "redefined."  There is no attempt to give
>> special meaning to xsi:type outside its definition in XML Schema.  All
>> use of xsi:type in instances is bound by XML Schema processing rules,
>> and is normatively defined there, not in XForms.  (But see point 4).
>> Instead of
>>    "the node satisfies all applicable XML schema definitions (including 
>>    those associated by the type model item property, by an external or
>> an   inline schema, *or* by xsi:type)"
>> Do you think it means the following?
>>    "the node satisfies all applicable XML schema definitions (including 
>>    those associated by the type model item property, by an external or
>> an   inline schema, *and* by xsi:type)"
>> If so, we hope that instead of re-issuing the erratum, you are satisfied
>> with our assertion here that it is XML Schema that normatively defines
>> xsi:type, not XForms.
> 
> I am satisfied that XForms is not attempting to give special meaning to
> xsi:type.  Perhaps this can be clarified in 1.1 drafts?
> 

We clarified it, see
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-using-atomic
for changes.

>> 2. We do not understand the reference to "widely deployed usages of
>> validated XML  Instances."XML Schema defines xsi:type for the  
>> substutition, restriction, or
>> extension of existing types.
>> A document that attempts to override the type of an element with an
>> unrelated type is not valid.
>> According to XML Schema, only with a type defined by restriction or
>> extension, and in some cases by substitution.
>> Please see http://www.w3.org/TR/xmlschema-1/#cos-ct-derived-ok
>> To test this point, I've taken your example below and defined schema.xsd
>> which I think describes the case.
>> It defines a type for the child element which contains only other child
>> elements, and a type called "newType" that contains grandChild elements,
>> which themselves are xsd:string.
>> Here is the Schema:
> ..snip
>> When I attempt to validate the stuff.xml document with a Schema
>> processor I get this error:
>>   Element '{http://sample.com}child', attribute
>> '{http://www.w3.org/2001/XMLSchema-instance}type':  The type definition  
>> '{http://sample.com}newType', specified by
>> xsi:type, is blocked or not  validly derived from the type definition of  
>> the element declaration.
>>   Element '{http://sample.com}grandchild': This element is not expected.
>>  Expected is ( {http://sample.com}child ).
>>   stuff.xml fails to validate
>> Do you know of a situation in which a Schema processor would allow
>> xsi:type to declare a type for an element which is in conflict with the
>> Schema type definition?
> 
> Only as you said by extension or restriction, which still can allow you to
> have instances that can't validate to be types.
> 
> Take this schema for an example:
> 
> <?xml version="1.0"?>
> <xsd:schema targetNamespace="http://sample.com"
>          xmlns:s="http://sample.com"
>          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>          elementFormDefault="qualified">
>          <xsd:element name="root">
>                  <xsd:complexType>
>                          <xsd:sequence minOccurs="1" maxOccurs="1">
>                                  <xsd:element name="child"
> type="s:childType" />
>                          </xsd:sequence>
>                  </xsd:complexType>
>          </xsd:element>
> 
>          <xsd:complexType name="childType">
>                  <xsd:sequence minOccurs="0" maxOccurs="unbounded">
>                          <xsd:element name="grandChild" type="xsd:string"
> />
>                  </xsd:sequence>
>          </xsd:complexType>
> 
>          <xsd:complexType name="newType">
>                  <xsd:complexContent>
>                          <xsd:restriction base="s:childType">
>                                  <xsd:sequence minOccurs="0"
> maxOccurs="unbounded">
>                                          <xsd:element name="grandChild"
> type="xsd:date" />
>                                  </xsd:sequence>
>                          </xsd:restriction>
>                  </xsd:complexContent>
>          </xsd:complexType>
> </xsd:schema>
> 
> Then validating this instance:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>    <root xmlns="http://sample.com"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xsi:schemaLocation="http://sample.com schema.xsd">
>      <child xsi:type="newType">
>        <grandChild>Stuff</grandChild>
>      </child>
>    </root>
> 
> shows that the value "Stuff" is not a valid xsd:date, for example
> 

Yes, we agree.

>> 3. Standalone Xerces
>> By Standalone Xerces, do you mean that processing the stuff.xml file
>> without access to the ssample.xsd schema file validates?
>> Given that there is no Schema information available, and there is no
>> type definition for xsi:type either, I believe that the best Xerces can
>> do is declare that the document is well-formed, and cannot test its
>> validity.  Do you disagree with this?
> 
> What I meant by "standalone", was validation done outside of an XForms
> processor.
> In the XML instance example I gave, it clearly indicated using
> xsi:schemaLocation which schema to validate against.  It should have
> access to the schema.xsd schema from a standalone validator, or at least
> an editing environment that supports XML validation.
> 

We agree. If you're using an instance outside XForms you can turn on Schema
validation by using xsi:schemaLocation. Note that this is only a hint to the
Schema processor, it is allowed to ignore the hint (see
http://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation for reference).

>> 4. In Schema validation, it is user of the document who gets to decide
>> what Schema to use, not the document itself.
>> To do otherwise would negate the value of Schema validation, as
>> nefarious instance data could circumvent its own validation!
>> For this reason, Schema processors are allowed to ignore
>> xsi:schemaLocation attributes in documents.
>> See http://www.w3.org/TR/xmlschema-1/#schema-loc which states
>>   Unless directed otherwise, for example by the invoking application or
>> by command line option, ...
>> In XForms, we take the xf:model/@schema attribute and the xsd:schema
>> child elements of xf:model to be direction from the invoking
>> application.
>> By #1 above, the xsi:type attribute in the instance cannot specify
>> anything in conflict with the Schema specified by the form author, so we
>> conclude that the correct behavior is to fail to submit because the
>> document is not valid.
>>
> 
> So if I understand what you are saying, these 2 statements are not equal:
> 
> 1)
> <xf:model schema="schema.xsd">
>     <xf:instance>
>        <t:root>...</t:root>
>     </xf:instance>
> </xf:model>
> 
> 2)
> <xf:model>
>    <xf:instance>
>      <t:root xsi:schemaLocation="http://sample.com schema.xsd">...</root>
>    </xf:instance>
> </xf:model>
> 
> Since as the author of #1 indicates the overriding schema to use for
> validation and
> author of content of #2 indicates what schema to use for validating
> separate instance.
> Also XForms processors can not take the schema in #2 and treat as the
> @schema attribute on <xf:model>, as
> has to process any xsi:type[s].
> 

Yes, you are right. XForms processors ignore any xsi:schemaLocation hints. So
it's the responsibility of the form author to provide a schema attribute on
element xf:model in order to process xsi:type attributes in terms of
validation.

Regards,
Ulrich Nicolas Lissé.
For the Forms WG

>> Leigh.-----Original Message-----
>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
>> Behalf Of Steve K Speicher
>> Sent: Monday, March 26, 2007 3:42 PM
>> To: www-forms@w3.org
>> Subject: Re: 1.0 errata section 10 (complex type validation
>> clarification)
>> See thread
>> http://lists.w3.org/Archives/Public/www-forms/2006Aug/0047.html
>> and resulting errata 
>> http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E10a
>> I find that the definition for validation in the errata is too strict
>> anddoesn't match that of some widely deployed usages of validated XML 
>> instances.
>> Take for instance this example:
>>  <!-- simple sample XForms model -->
>>   <xf:model schema="schema.xsd">
>>     <xf:instance src="stuff.xml" />
>>   </xf:model>
>>  <!-- stuff.xml -->
>>   <root xmlns="http://sample.com"
>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>>     xsi:schemaLocation="http://sample.com schema.xsd">
>>     <child xsi:type="newType">
>>       <grandchild>Stuff</grandchild>
>>     </child>
>>   </root>
>> According to the errata it says:   "the node satisfies all applicable  
>> XML schema definitions (includingthose associated by the type model item  
>> property, by an external or aninline schema, or by xsi:type)"
>> If for example, my "newType" defines a conflicting complex content model
>> for <child> then there is no way for my instance to validate, therefore
>> itcan never be submitted.  If you validate the instance using a  
>> standalone
>> validator such as Xerces, it validates fine.
>> I believe the wording is intended to state that the node is valid if it 
>> passes validation for both these:
>>   1) external or inline schema, as possibly redefined by xsi:type
>>   2) type MIP
>> The errata wording seems to indicate that both external/inline schema
>> andxsi:type schema type definitions should be used.Regards,
>> Steve Speicher

Received on Thursday, 14 June 2007 14:02:13 UTC