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

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.

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:
<?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="child" type="s:childType" />
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="newType">
    <xsd:sequence minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="grandChild" type="xsd:string" />
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

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?

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?

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.

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 Wednesday, 28 March 2007 17:50:19 UTC