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

Hi Allan,

The problem is occuring due to the selection of a particular sentence 
that, when taken out of context, could be read in a different way than 
when it is in context.
We need to read the material in context because there's no way to put all 
the intended meaning into every single sentence.
And the interpretation you give takes on two contradictions when put in 
context. 

So, I think the interpretations are not *equally* valid.

The *first* thing the spec says is that type assigns a schema datatype. 
This makes a ton of sense because the client-side needs input validation; 
structural validation we get because we build XForms with stock components 
like a schema engine.  Most structural errors would not be fixable by the 
client-side end-user.

Anyway, the *second* thing it says is that the effect is the same as using 
xsi:type.  Well, it is the same in the context of datatype validation, 
which is what I contend the author of the section meant.  It's not 
strictly equivalent, which is why we need a clarification erratum, which I 
already have the action item to write.

The *third* thing the section says is essentially "see how type is *not* 
equivalent xsi:type" but actually better because you can attach it to 
attributes.

>From a language consistency standpoint for XForms 1.0, there are even more 
contradictions if we open the context to the whole recommendation, but 
from the occam's razor point of view, assuming one less than perfect 
sentence trumps two bonafide contradictions.

Finally, the interpretation of the type MIP as datatype validation only 
means goodness for XForms basic.

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/05/2006 03:45 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/4/06, John Boyer <boyerj@ca.ibm.com> wrote:
> Because others may not want to go fishing for that email, I'll explain 
again: I asked what other
> implementers were doing when a form author attempts to assign a 
non-datatype using the
> XForms type MIP.  You responded that you didn't understand the question 
because a datatype
> can be simple or complex and then asked what was missing...
>
> The issue is that the notion of datatype is clearly defined in XML 
schema to be a validation
> of character string content.
>
> The datatype of string content could come from a simple type or from a 
complex type.
>
> The part I believe you were missing from my last post was that I did not 
make note to the
> reader of the fact that complex types can exist for more than one 
reason.  Some complex
> types still only assign simple content to the elements they describe. 
These are elements
> that have no element children (this includes mixed content, of course).

I missed something, I agree :) What I missed is this:
"Description: associates a Schema datatype."
[http://www.w3.org/TR/2006/REC-xforms-20060314/slice6.html#model-prop-type]
and the definition of "datatype":
http://www.w3.org/TR/xmlschema-2/#datatype
and somebody to clearly spell out "datatype" to me. I missed that,
again and again. I've read "type" all the time, especially because of
that "xsi:type" equality sentence.

> I asked what others are doing partly to raise awareness of what the spec 
actually says about
> the type MIP because I've heard a lot of comments recently that caused 
me to believe that
> at least some folks believed that the type MIP could be used to assign a 
structural complex
> type, so I've asked the working group members and implementers to have a 
look at this issue.

With _the current specification_, it's an implementation issue,
because the spec. contradicts itself imho. You focus on the
"description" line, I focus on the "equality with xsi:type". Until we
have a resolution fixing this somehow, I would say both approaches are
just as valid -- or invalid :)

--
... Allan