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

Maybe I am not reading the same spec as everyone else, but this thread 
seems to have gone
off the tracks from the beginning.

Section 6.2.1 is very short.  It says that *XForms* derives type 
information from a list of sources.
It says that if more than one source is available, then a node must 
satisfy the type restriction 
indicated by each source.  It even says that the sources can assign 
disagreeable types that
make it impossible for a node to ever contain valid data, and it says that 
authors should do this.

But since this is not a spec for authors but rather for implementers, it 
is telling implementers that
it is OK for the implementation to never allow the node to be valid when 
the author has done this
because assigning disagreeable types is poor form application design.

I don't see how this has turned into the need for some sort of inheritance 
or precedence model.
There are separate sources of information and the XForms processor tests 
each in turn, and
logically AND's the results.

I especially don't see where it says that type MIP "is like xsi:type" 
thereby implying some effect
of the type MIP on the PSVI.  This is especially true because XForms does 
not strictly require
a PSVI-capable schema processor, nor does it require a host language to 
even have a CSS
processor such that hypothetical effects of the type MIP on the 
non-required PSVI could be 
operated on by the non-required CSS selector.

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/boyer/index.jsp





Lars Oppermann <Lars.Oppermann@Sun.COM> 
Sent by: www-forms-request@w3.org
04/06/2006 03:11 AM

To
Allan Beaufour <beaufour@gmail.com>
cc
"Nick_Van_den_Bleeken@inventivedesigners.com" 
<Nick_Van_den_Bleeken@inventivedesigners.com>, www-forms@w3.org
Subject
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