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

Allan Beaufour wrote:
> On 4/5/06, Nick_Van_den_Bleeken@inventivedesigners.com
>> I'm also no schema master ;), But it can be that it is the case if you
>> read the schema spec, but is that what the original authors of the XForms
>> spec meant, and more important is that how the users/implements think/want
>> that it works.
>> In my opinion it would be hard to sell that we have type constraints but
>> we only allow derivations of the type that was specified in the schema.
> 
> In general I do not believe that XForms should run off and create
> XForms-specific solutions for problems solved elsewhere. XML Schema
> defines how this should work, and XForms should just adhere to that.
> 
> That said, as Steven correctly noted, Leigh pointed out a problem with
> this wrt XForms Basic. So we need to fix something in the "bind type
> is the same as xsi:type"-paragraph. To avoid conflicting we should
> check the "bind type" seperately from the schema+xsi:type defined
> types. The result will be that you can have an element with both
> xsd:anyURI and xsd:string as types.

I agree that the "bind type is like xsi:type" seems to be the major 
source for confusion. By saying so, the spec implies, that the binding 
would have an effect on the PVI (post validation instance) and as such 
interact/layer, with the applied schemas (as Leigh pointed out). Bind 
type however does not change the PVI (or does it, since it is to behave 
like xsi:type?), it is a MIP and could be viewed as some other way to 
express a constraint, plus giving a control an idea of what/how it 
should render/behave.

Now, I'm probably ignoring some important fact, so please correct me - 
Everything that can be done with bind type, could be done with a 
combination of constraints, appearances and css; so why is it needed?

Wouldn't it be cool, to have access to the type information in the PVI 
and have some sort of CSS selector through which controls, that are 
bound to a particular type can be accessed?

I can see how bind type is a convenient way to work with types when 
there is no schema support available, but maybe it would be more clear 
to find a better integration with xsi:type for those cases (which in 
turn does not work for attributes).

Those thoughts aside, I absolutely agree  with what Alan said about 
making a clear distinction between schema-/xsi:type and bind type, in 
which the bind type MIP clearly sits in a layer on top of any PVI types. 
Should the PVI type and bind type have disjunct domains, the instance 
could never be valid. In order for an instance to be valid, both bind 
types and PVI types need to be correct.

/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 Thursday, 6 April 2006 10:11:59 UTC