Re: Digging through section 6.2.1 / multiple types for an element

Allan Beaufour wrote:
> One problem is that <bind type="xsd:date"/> would then not "trigger a
> datepicker control" if it is only used for validation. So it needs to
> influence the type in general, not just for validation purposes. But
> what should a control bound to an element with both an xsi:type and a
> <bind type=""/> use as "its type"?
> 

The datepicker control should be triggered by the fact, that the 
type-MIP of the bound node is of xsd:date type. The type-MIP currently 
has no relationship to the schema type - except, when the schema type 
was set via xsi:type, because xsi:type has a meaning in xforms too.

> So bind type is there to:
> 1) Add an extra, "autonomous", type validation check to elements
> 2) Add type information to elements for presentation purposes ...

Repeating what I said above, the thing is, we say, that xsi:type has 
meaning in XForms. It already has a meaning in schema although that is, 
by definition, unrelated to the meaning in XForms.

 From an authors perspective, I would argue, that if my schema says 
something is an xsd:date, my controls should know about that, without me 
explicitly specifying xsi:type="xsd:date" in my instance or even 
creating a bind-type. This however would require the results of the 
schema-validation to be pushed into type-MIP land.

I would see bind-type as xforms way around a requirement for PSVI 
access. Under this assumptions, I dare say, that xsi:type shouldn't have 
a meaning in XForms at all.

On the other hand, I bet there are good reasons for xsi:type to have a 
meaning in the xforms model. Please enlighten me :)

Cheers,
/lars

-- 
Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
Software Engineer - StarOffice                           Sachsenfeld 4
Phone: +49 40 23646 959                                D-20097 Hamburg
Fax:   +49 40 23646 550                  http://www.sun.com/staroffice

Received on Friday, 7 April 2006 10:48:22 UTC