RE: 1.0 errata section 10 (complex type validation clarification)

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?

> 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

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

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

> 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
> and 
> doesn'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 (including 
> those associated by the type model item property, by an external or an 
> inline 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
> it 
> can 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
> and 
> xsi:type schema type definitions should be used. 
> 
> Regards,
> Steve Speicher

Received on Thursday, 29 March 2007 14:04:00 UTC