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

On 4/9/06, John Boyer <boyerj@ca.ibm.com> wrote:
> 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.

I'm trying to follow you. You are saying that 1) bind type="" only
specifies type (validation) information which is handled seperately
from the schema attached information, and 2) it might be used for
presentation purposes, but you do not care how. Or?

--
... Allan

Received on Tuesday, 11 April 2006 11:12:06 UTC