Forms Working Group Teleconference

27 Mar 2013


See also: IRC log


pfennell, +1.323.425.aaaa, nvdbleek, Steven, [IPcaller], alain, ebruchez


<trackbot> Date: 27 March 2013

Action item review


Steven: Some people have a lot of them
... A lot of mine were items I never closed
... There are 2 large ones that are still on my radar, will do them when we come closer to publication
... pfennell you have a couple, can you close the ones that are done?

pfennell: Will do

Steven: alain can you go over your list?

alain: I can't list my action items
... authorisation is rejected

Steven: Nick you have some

nvdbleek: planning to do some this week

[ACTION-1934] Completed (Update the XML and relax-ng schema (change mediatype to accept on upload))


nvdbleek: I will do this one this week

The function Element




ebruchez: We wanted to have the element, Uli proposed to drop it, I was not sure. Now I'm in favour of keeping it

discussing http://lists.w3.org/Archives/Public/public-forms/2013Mar/0018.html

ebruchez: The main problem I have is the heavy syntax
... If we only have the lighter weight syntax then we loose variable support when using XPath as expr. lang, so I'm proposing of supporting both the lighter and the heavier syntax

Light weight:

<function signature="my:sumproduct($p as xs:decimal*, $q as

xs: decimal*) as xs:decimal">

sum(for $i in 1 to count($p) return $p[$i]*$q[$i])


Full syntax:

<function signature="my:sumproduct($p as xs:decimal*, $q as

xs: decimal*) as xs:decimal">

<result value="sum(for $i in 1 to count($p) return $p[$i]*$q[$i])"/>


With variables:

<function signature="my:foo($p as xs:decimal*) as xs:decimal" override="no">

<var name="v1" value="$p[1]"/

<var name="v2" value="$p[2]"/

<result value="$v1 + $v2"/>


You can also specify the language of the function:

<function signature="my:foo($p as xs:decimal*) as xs:decimal"

override="no" type="text/javascript">



<ebruchez> <function><result>expression</result></function>

ebruchez: if you have a bigger expression in text would look nicer then in an attribute

nvdbleek: For consistency I think we should keep it as an attribute

ebruchez: for the expression the function in the lightweight syntax it is text content, that looks nicer

<ebruchez> <function><var/><var/><result>very large expression</result></function>

Steven: Are we all happy with it?

alain: Yes

nvdbleek: yes

Steven: We need some text

nvdbleek: It are only minor changes to spec

RESOLUTION: We will go with the lightweight and heavier syntax for the function element

<scribe> ACTION: nvdbleek incorporate Erik's proposal about a lighter weight syntax for the function element [recorded in http://www.w3.org/2013/03/27-forms-minutes.html#action01]

<trackbot> Created ACTION-1940 - Incorporate Erik's proposal about a lighter weight syntax for the function element [on Nick Van Den Bleeken - due 2013-04-03].

ACTION-1932 - Suggest text spec for target keywords referring to host language


ebruchez: It is about submitting to another window
... The target attribute is basically the HTML target attribute

<ebruchez> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#valid-browsing-context-name-or-keyword

ebruchez: the value is a bit funny
... so the target works well when the host language is HTML
... for other host languages we don't want to do the same thing
... So I made the values host-language and implementation dependent, recommending the HTML values when the host language is HTML
... the question arises what to do with the show attribute because it does similar things, but target does more
... If both are specified and the implementation supports the target attribute the target attribute will win, so the show attribute is more 'reliable' to use across implementations

Steven: Erik can you ask Michaeals feedback

ebruchez: it is a bit annoying to have two attributes doing the same thing, I'm not happy with this
... We could deprecate the show attribute, and mandate that the target attribute supports _blank and _self
... the only problem is that I think we shouldn't specify the complete value space for all platforms
... I also noted that the load element was referencing Xlink quite a bit...
... I don't think a lot of people would mind if we are in line with Xlink or not

Steven: you could have show="replace" and target="_self"

ebruchez: those are the default, so I don't think you use them a lot
... In our implementation we just forward the target attribute to the browser, which handles it

Steven: currently we are very neutral about the host language

ebruchez: the values for target are ugly

nvdbleek: I don't have a strong opinion about it, but I think we should support the target attributes if you are using HTML as a host language

Steven: another option would be show="target" and in that case you should use the target attribute to specify the target

ebruchez: this makes it a bit more complicated, because you should always write both the show and target attribute
... we could make the default value of show target if you specify a target attribute
... on submission you don't have a show attribute, only a target attribute

<Steven> So with submission we would have replace="all" target="mytab"

<Steven> So consistent would be load show="replace" target="mytab"

ebruchez: there is no clash with other attributes on submission
... replace is the default for show on load

<ebruchez> show="replace" target="_blank"

ebruchez: when you do show="replace" target="_blank" will not replace the form but will open an new window

Steven: I don't see that as a big problem

nvdbleek: We need to be sure then that we don't imply that the xforms processor is shut down you do a submission with replace all, because when you have a different target the form will keep running


all: the event xforms-submit-done may be dispatched with appropriate context information, and submit processing concludes with the entire containing document being replaced with the returned body.

ebruchez: This is not correct

<Steven> It depends on the meaning of "containing document"

ebruchez: The xforms spec uses different wording
... html uses a browsing context
... xforms uses 'presentation context'

<ebruchez> HTML: "browsing context"

<ebruchez> XForms: "presentation context" (load action)

ebruchez: the submission uses document
... the desired behaviour is clear it will replace the 'presentation context'/'document' of the target

Steven: We might need to tweak the wording a bit, but the direction is good

<Steven> trackbot, end call

<trackbot> Sorry, Steven, I don't understand 'trackbot, end call'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<Steven> trackbot, end telcon

Summary of Action Items

[NEW] ACTION: nvdbleek incorporate Erik's proposal about a lighter weight syntax for the function element [recorded in http://www.w3.org/2013/03/27-forms-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-03-27 16:00:44 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Leight/Light/
Succeeded: s/functin/function/
Succeeded: s/lightweight syntax/lightweight and heavier syntax/
Succeeded: s/self/_self/
No ScribeNick specified.  Guessing ScribeNick: nvdbleek
Inferring Scribes: nvdbleek
Default Present: pfennell, +1.323.425.aaaa, nvdbleek, Steven, [IPcaller], alain, ebruchez
Present: pfennell +1.323.425.aaaa nvdbleek Steven [IPcaller] alain ebruchez
Regrets: Uli
Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Mar/0022
Found Date: 27 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/27-forms-minutes.html
People with action items: nvdbleek

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]