- 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 list. 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. Cheers, 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 To John Boyer/CanWest/IBM@IBMCA cc www-forms@w3.org Subject Re: Because type is for datatype, there should not be a problem for XForms Basic Hi 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? E.g. <data> <value>v</value> </data> 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, David
Received on Wednesday, 3 May 2006 19:04:50 UTC