W3C home > Mailing lists > Public > public-xformsusers@w3.org > July 2013

Re: Some remaining action items

From: Erik Bruchez <erik@bruchez.org>
Date: Tue, 2 Jul 2013 15:09:13 -0700
Message-ID: <CAAc0PEVewvna3RYGwxbhOqJcTDBX8qjpKLUd1FW6FF3=dthPJg@mail.gmail.com>
To: John Boyer <boyerj@ca.ibm.com>
Cc: public-forms@w3.org, "public-xformsusers@w3.org" <public-xformsusers@w3.org>

Thanks for the feedback.

The "other" MIP functions have a better chance of success if they state not
> just that they return the value of the MIP, but that they set up a
> computational dependency on the MIPs as if they were "shadow" instance
> data.  This would ensure that calculations which invoke MIP functions run
> after all calculations that may update the values of the MIPs.

It does make sense of course, but we won't get this far for XForms 2.0 I
fear! We had already resolved to support plain MIP functions, which already
have utility in particular in the view and in actions.

Currently, we say that using these functions on binds *should* raise
exceptions, and explain why using them this way is dangerous.

> Validity is a little harder because it includes validity information that
> is only evaluated after recalculate, i.e. during revalidate.

Yes this is harder, and to get there the processing model might even need
to get rid of the current recalculate/revalidate split.

> Also, for this reason, it would be helpful to have a required() function
> and a constraint() functions that return the consolidated results of the
> required attributes and constraint attributes, respectively. In other
> words, the required MIP and constraint MIP consolidate the attributes, as
> already specified, and the functions just A) return the value of the MIP,
> and B) set up a dependency on the MIP value.

In addition type information also contributes to the validity of a node.


> Cheers,
> John M. Boyer, Ph.D.
> IBM Distinguished Engineer & IBM Master Inventor
> @johnboyerphd | boyerj@ca.ibm.com
> From:        Erik Bruchez <erik@bruchez.org>
> To:        public-forms@w3.org, "public-xformsusers@w3.org" <
> public-xformsusers@w3.org>,
> Date:        12/06/2013 08:03 AM
> Subject:        Some remaining action items
> Sent by:        ebruchez@gmail.com
> ------------------------------
> All,
> Looking at what's on my plate (or might end up on it), I see:
> 1. ACTION-1933 - Suggest spec text for MIP functions
> The valid() function is already there. [1] What's missing is adding
> the functions to access the other MIPs,
> relevant()/required()/readonly(). That should be pretty easy.
> 2. ACTION-1896 - Send a e-mail to Michael Kay about providing type
> information to the nodes in instances
> This is an old action item. The original question I think is obsolete,
> but the new question on this is whether it is reasonable to compile
> XPath expressions without knowing *any* node types, but to provide
> those types at runtime when the expression runs. I think it should be,
> but it'd be good to double-check.
> 3. Integrate xf:dialog spec
> I don't think there is an action item on this one, but we had decided
> to do it. There is a resolution for show/hide [2], but no action item.
> We need one.
> 4. ACTION-1948 - Provide spec text for multipart
> This is a late-minute feature, but we discussed it and I was under the
> impression I could write up something "quickly".
> 5. ACTION-1868: Bruchez to summarize problems with error handling and
> three options for variable type handling
> This is an older action item, and I had it on hold. Not sure what to
> do with it right now, clearly a P2 for now.
> I don't know about other people's action items.
> Finally, I am pretty sure some of the XForms 2 text hasn't been
> reviewed (at least by me).
> -Erik
> [1]
> http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_valid.28.29_Function
> [2] http://www.w3.org/2013/01/30-forms-minutes.html
Received on Tuesday, 2 July 2013 22:10:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:42 UTC