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

In prior comments I said that the type MIP is separate from xsi:type,
and that it was part of the XForms processor information set as opposed 
to being intermixed with the schema engine information set.

The discussion I intended to participate in was related to the decisions
made by the XForms model, because this is what Section 6.2.1 is about.

Agreed that Section 8 also refers to consumption of type information and
that you were also discussing that.  However, the ambiguity there about 
what to do when multiple channels of type information conflict is 
hopefully a separate problem again. 

By "hopefully" I mean that I hope that resolution of the ambiguity does 
not drive more requirements onto the model processor, such as that XForms
type MIP information must be integrated into the underlying schema engine.

One reason I *believe* the UI decision about type information is a 
separate problem is that it is not even *required* that an XForms
processor consume the information.  An implementation *might* show a 
calendar control if an input is bound to a node of type xsd:date.
To me this leaves all sorts of flexibility for user agents to do
somewhat different things here *even in valid use cases*, not to mention
the invalid case where the type information is conflicting.

There are several vectors along which user agents may have to vary
behavior.  Some might have a hard time detecting that the node is 
a date type when it is not specifically xsd:date.  Other user agents 
might only show a calendar control if locale information indicates that
a Gregorian calendar is appropriate while showing a free form input
control otherwise.

Granted the spec specifies no order for the UI control to query the 
channels of type information available in the information set 
available from the XForms model, but the workaround for the invalid
use case of conflicting type information is already so simple that 
it seems reasonable to say just pick an order, implement, and move on 
to a more important problem.

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





"Allan Beaufour" <beaufour@gmail.com> 
Sent by: www-forms-request@w3.org
04/07/2006 05:15 AM

To
"Lars Oppermann" <Lars.Oppermann@sun.com>
cc
www-forms@w3.org
Subject
Re: Digging through section 6.2.1 / multiple types for an element







On 4/7/06, Lars Oppermann <Lars.Oppermann@sun.com> wrote:
> 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.

Yes I agree, that is what I am trying to say. But also by any type
associated by the schema. And that's were we can have a possible
confusion of types.

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

With the current spec. and the "bind is like setting xsi:type" I would
say that it definately has a relationship with the schema type. This
was the point of my first mail.

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

Yes, 6.2.1 should probably be revised too. We should not mention
anything about xsi:type. That's handled by schema.

>  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 say that anything setting the type on an element should be
known to my control. I would expect that for implementations of the
current spec.

> 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 :)

If you are saying that we should refrain from mentioning xsi:type
specifically in section 6.2.1, then yes. If you are saying something
else, I'm confused :)

--
... Allan