Re: Some test cases for the type MIP

Hey that's good to hear, Aaron.

Other than having the ability to associate built-in datatypes and nodes 
without expressing a schema, 
the main thing that makes the XForms type MIP meaningful to me is that you 
should be able to say
in XForms that type="xsd:decimal" and not care whether the element has 
attributes or not.

Moreover, since our default is xsd:string, I think that one *must* have 
this interpretation otherwise
every simple content element with attributes would be invalid unless a 
type is explicitly declared.

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





Aaron Reed <aaronr@us.ibm.com> 
Sent by: www-forms-request@w3.org
05/12/2006 04:32 PM

To
www-forms@w3.org
cc

Subject
Re: Some test cases for the type MIP







Hey John,

Well, Mozilla will validate the *content* of the node against the type 
MIP while the user is filling out the form.  If there is a type applied 
via schema we'll forward the type to the node and still only validate 
the content I believe.  We haven't hooked up submission to our limited 
schema support, yet, but that will be where we run up against validating 
the element (attributes and all), because we'll validate the whole 
instance document against the schema at that point.

--Aaron

John Boyer wrote:
> 
> Since the topic of implementations has come up, I think it makes a 
> little sense to talk
> about what mine is doing and try to see whether other implementations 
> are doing
> similar things.  I'm guessing there are some differences...
> 
> As is no doubt painfully clear by now, my interpretation of the type MIP 

> is validation
> of the datatype against the *content* of the node with which the 
> datatype has been
> associated.  This means both of the following validate in my 
> implementation:
> 
> <instance>
>    <data>
>       <price>100.00</price>
>       <price currency="USD">100.00</price>
>    </data>
> </instance>
> 
> <bind nodeset="price" type="xsd:double"/>
> 
> Does anyone agree or disagree that the second price element should be 
> considered
> valid according to the type assignment made?  I ask because the schema 
> declaration
> for the price element would be a complex type that adds the currency 
> attribute to a
> *base* of xsd:double.
> 
> If your implementation considers the second price to be valid, then your 

> implementation
> is validating the content of the price element.  If your implementation 
> doesn't validate
> the second price element, then you are validating the whole element, 
> attributes and all,
> and we have a new disconnect to contend with.
> 
> Recently, some suggestions were made at the last XForms face-to-face 
> that the type
> MIP could consume complex types.  I interpreted these comments in the 
> context of
> datatype validation, so we have experimented with adding some code that 
> attempts
> to accommodate this desire.  I make no guarantees that the code will 
> stay there :-), but
> additional of complex types with simple content necessitates *two* type 
> checks, one
> with attributes and one without attributes.  Here is an example:
> 
> <xsd:complexType name="internationalPrice">
>    <xsd:simpleContent>
>      <xsd:extension base="xsd:double">
>        <xsd:attribute name="currency" type="xsd:string"/>
>      </xsd:extension>
>    </xsd:simpleContent>
> </xsd:complexType>
> 
> <instance>
>    <data>
>       <price currency="USD">100.00</price>
>       <price currency="EUR">100.00</price>
>    </data>
> </instance>
> 
> <bind nodeset="price[1]" type="xsd:double"/>
> <bind nodeset="price[2]" type="internationalPrice"/>
> 
> With the experimental code, both price elements above are valid.  The 
> first because
> the simple type validates the *content only* of the (first) price node, 
> and the second
> because the complex type validates the actual (second) price element.
> 
> How do these results compare with other implementations?
> 
> Thanks,
> 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
>