See also: IRC log
<trackbot> Date: 27 March 2013
http://www.w3.org/2005/06/tracker/xforms/
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
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0013.html
nvdbleek: I will do this one this week
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0018.html
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0019.html
http://lists.w3.org/Archives/Public/public-forms/2013Jan/0028.html
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])
</function>
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])"/>
</function>
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"/>
</function>
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">
foo(XForms.var.p);
</function>
<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].
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0020.html
ebruchez: It is about submitting
to another window
... The target attribute is basically the HTML target
attribute
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
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]