Report on Using XML Schema Structures from the XForms-XML Schema Task Force

Greetings,
 
     This summary report comes to you from the XForms-XML Schema Task
Force. The Task Force was asked to report on the use of XML Schema
Structures within the XForms Model. This report is intended to explain
the conclusions of the Task Force with regard to the subset of XML
Schema used in XForms. It represents the sense of the Task Force as a
whole rather than that of any individual member.
 
     The XForms-XML Schema Task Force has already created a subset of
XML Schema Datatypes for use in the XForms Basic profile, and agreed
that the full set of XSD datatypes may be used in the "full" profile.
Schema implementations to this end are available from the Task Force
archives.
 
 XForms 1.0 processes instance data based mainly on an initial XML
instance data fragment. The design externally annotates the instance
data with properties such as readOnly, calculate, relevant, and so on.
(Such fragments are only required to be WFXML.)
 
 After much discussion, the Task Force has concluded that there is no
need for any part of XML Schema Structures in the XForms 1.0 Basic
Profile. Suitable methods have been proposed to accomplish all of the
necessary tasks required for XForms Basic processing on small or limited
devices without the use of XSD Structures, through the use of
annotations on specific information items to indicate their data types.
Further restrictions such as minOccurs/maxOccurs can also be
accomplished using this annotation method, using dynamic constraint
attributes defined in the XForms namespace.
 
 One issue of note in this solution is that an XForms Model constructed
of information items using XML Schema datatypes is not an XML Schema in
the sense described in the XML Schema Recommendation. It is therefore
not subject to Schema Validity Assesment (SVA) and no Post-Schema
Validation Infoset (annotated infoset) will result from performing
low-level integrity checks on such a document. This is precisely why
this solution was chosen, as it permits the use of XSD datatypes while
reducing the barriers to conformance on small devices, in accord with
the Task Force's mission. This does not prevent an SVA on the overall
XForms document that contains these information items, which would
result in the creation of a PSVI.
 
 Perhaps a more elegant approach for the future would be to make XForms
a full-blooded member of the XML Schema/XML Query/XML Protocol/XPath 2.0
family. This could include:
 
  * A fully specified PSVI as part of the XForms Processing Model
  * Using XPath 2.0 for binding expressions
  * Defining XML Protocol submit methods
  * Extensive cross-group coordination (!)
 
While this approach has benefits, timelines seem to preclude XForms 1.0
from the necessary time frame. A future version of XForms could start
with such a foundation.
 
     The Task Force looks forward to receiving comments and questions
about this report. Please send all comments to w3c-forms-schema@w3.org
<mailto:w3c-forms-schema@w3.org> .
 
Regards,
 
Daniel Austin, Chair
 
***************************************************
Dr. Daniel Austin, Director of Research and Development
Mozquito Technologies AG Munich Germany
+49 89 38380851 daustin@mozquito.com <mailto:daustin@mozquito.com> 
Sapere Aude!

Received on Monday, 16 July 2001 06:58:08 UTC