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

Received on Friday, 7 April 2006 12:15:52 UTC