- From: Klotz, Leigh <Leigh.Klotz@xerox.com>
- Date: Wed, 28 Mar 2007 10:49:42 -0700
- To: "Steve K Speicher" <sspeiche@us.ibm.com>
- Cc: <www-forms@w3.org>, <www-forms-editor@w3.org>, <public-xforms@w3.org>
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:21 UTC