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

Hi Allan,

My view is not just one concrete immutable view based on a particular 
implementation,
which is something that we all too commonly say to one another when our 
implementations 
don't exactly agree :-(

The authors and editors of XForms took the trouble not only to cite XML 
schema part 2 when
using the word datatype, but also the notions of value space, lexical 
space, and facets.
There is just no way to argue that they had only passing familiarity with 
the concepts and
misused the word datatype.  I am not saying you said this in particular, 
but only that it has
come up on this thread and that, at the very least, you do want datatype 
to mean any 
schema type.

Anyway, after these citations in Section 5, we have 6.1.1, which defines 
the type MIP from XForms.
The type MIP is described as associating a datatype.  It's legal values 
are defined to be
those that represent a datatype.  Then, the real clincher, its default 
value is given to be xsd:string.
It is just not reasonable to get complex types out of that sequence of 
facts.

Nonetheless, because I do understand compromise, I have been trying to 
make sense of the
suggestion that the type MIP could refer to complex types.  I found that 
if I tilt my head and squint
just the right way, and go down several levels to the most relaxed 
meanings of the words associate
and represent, then maybe one could sneak in a bit of indirection and 
reference complex types that
have simple content.  Based on this *we actually did change our 
implementation* to be a little more
inclusive, though we still restrict type MIP validation to nodes with 
simple content.

But compromise doesn't mean letting everything go by. XForms 1.0 was 
designed to have a 
lightweight mechanism for assigning datatype (character string) validation 
to nodes without 
needing to invoke heavyweight schema.  The relaxation to complex types 
with simple content
is at least useful to authors because they can validate simple content of 
elements with attributes
without being forced by XML schema to describe the element's ancestry. 
But, if you actually
do need the full machinery of schema (i.e. including structural 
validation), then the W3C
already has a language for that called XML Schema... and XForms full 
supports it.

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





"Allan Beaufour" <beaufour@gmail.com> 
Sent by: www-forms-request@w3.org
05/11/2006 04:24 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







On 5/8/06, John Boyer <boyerj@ca.ibm.com> wrote:
> By context, I mean the XForms recommendation, specifically Section 
6.1.1, which is the
> one we are going 'round and 'round discussing the meaning of.  I cannot 
see how that
> was unclear in my last email on this thread.

That was also my assumption, but instead of guessing and possibly
misinterpreting, I asked.

But I give up. We have different views. I try hard to see it from both
sides, from a generic context of "XForms", without counting words or
regards to how many years I have had a personal view of something. You
seem to have one concrete (implementation?) view, and that is
apparently the absolute truth. It's hard, if possible at all, to
discuss then.

-- 
... Allan