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

On 4/6/06, John Boyer <boyerj@ca.ibm.com> wrote:
> OK, yes there is a typo in the subject line of this thread, so I didn't look at 6.1.1.

It's not a typo. If you read my mail you can see my train of thoughts
from 6.2.1, which leads to 6.1.1. I've even included direct links to
each section that I quote -- including a section number.

> So, agree we need to correct 6.1.1 so that instead of saying "The effect of type is the
> same as xsi:type" to say "The effect of type MIP is the same as xsi:type *on the
> information set provided by XForms processor and the validity conclusions drawn
> by xforms processor*"

Imho, that just obscures it. What is "information set"? I think we
need to figure out, what we are trying to accomplish with <bind
type="..."/>.

Based on the point that Leigh has raised, and what Lars also
discusses, it clearly needs to be seperated from the "generic schema
validation"-part of the processing (as in: it should not influence
it). So naïvely <bind type="..."/> is 1) only used for validation and
2) checked seperately from any other validation checks done by the
processor. As we talked about, this will also "solve" one of the id()
questions raised in another thread.

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"?

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 ...

How do we define 2)? Especially if there are conflicting types. It
might not make sense, but we still need to define what happens.

--
... Allan

Received on Friday, 7 April 2006 08:24:04 UTC