W3C home > Mailing lists > Public > www-forms@w3.org > April 2006

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

From: Allan Beaufour <beaufour@gmail.com>
Date: Tue, 11 Apr 2006 13:12:01 +0200
Message-ID: <90d6cb0e0604110412r3920bfd8h2c43a99f7aa43157@mail.gmail.com>
To: "John Boyer" <boyerj@ca.ibm.com>
Cc: www-forms@w3.org

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:17 UTC