W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

Re: Because type is for datatype, there should not be a problem for XForms Basic

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 3 May 2006 12:04:33 -0700
To: David Landwehr <david.landwehr@solidapp.com>
Cc: www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OF2038F38A.4D88B617-ON88257163.006712B9-88257163.0068C8F2@ca.ibm.com>
Hi David,

This is a problem with having the technical discussions on the public 
I believe that everybody is speaking for themselves and trying to work 
through to closure until 
"For the working group" appears.

On the technical question you asked, I think that mixed content would 
never be invalid according to 
the XForms type MIP because XForms type is only for assigning datatypes, 
which means to me that
the type MIP has nothing whatsoever to do with elements that do not 
contain datatype-able content.
So, the question of valid/invalid according to XForms type would not even 
be asked of an element 
that has element children. 

The example you give below of xforms:input ref="/data" would actually 
cause a binding to the first 
text node child of the data element, not the data element itself.

So, yes I agree that a bit of clarification may be needed, but it's 
hyperbolic to say the whole system is
broken.  The spec says type is for datatype validation.  As long as it is 
constrained to validity checking
of actual character strings, then I don't see why we have to throw the 
whole thing out.

The clarifications are needed because different people who speak English 
use the term "is the same as"
in different ways.  The author of that section clearly meant to establish 
a similarity for the reader, not a 
lock step equivalence.  This is easy to prove since the same author just a 
few lines above said that the
type MIP assigns a datatype and the same author just a few lines below 
says look how the XForms type 
MIP is cooler than xsi:type because you can assign it to an attribute. 

So, in conclusion, yes it would be very cool to have a completely 
rearchitected schema validation 
system, not just to consolidate channels of type information but also to 
make them seamlessly available
to all manner of calculations.  But, as far as I know, this level of 
rearchitecture is in the domain and 
requirements stream for XForms 2 and beyond.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

David Landwehr <david.landwehr@solidapp.com> 
Sent by: www-forms-request@w3.org
05/03/2006 11:33 AM

John Boyer/CanWest/IBM@IBMCA
Re: Because type is for datatype, there should not be a problem for XForms 


For clarity could you please write if this is the official WG answer or 
your own opinion (when I read this aloud it sounds like the WG answer)?

> When an unrecognized type is referenced, it defaults down to 
> xsd:string, which matches pretty much everything.
But then mixed content will always be invalid, correct?

and <xforms:input ref="/data">... if no datatypes is assigned to <data> 
and it defaults to xsd:string, then it will be invalid because of the 
<value/>. Is that really what the working group intent? The very funny 
implication of this is that a form with an instance that has no types 
assigned and has more than a document element will always be invalid and 
will never submit (unless you go to corner examples as having a ref to a 
node with hasn't got element in its content).

IMO the validation scheme used in XForms is totally broke and under 
specified and should be fixed from scratched.

Best regards,
Received on Wednesday, 3 May 2006 19:04:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC