See also: IRC log
<trackbot> Date: 06 March 2013
<alain> Hello! Yes I can.
http://lists.w3.org/Archives/Public/public-forms/2013Mar/0000.html
<scribe> scribe: nick
<scribe> scribenick:nvdbleek
nvdbleek: For the Europe people due to DST the next two weeks the call will be one hour later
http://lists.w3.org/Archives/Public/public-forms/2013Jan/0023.html
nvdbleek: I already handled the wrongly deprecated the mediatype element of upload in favor of @mediatype
is plain wrong. I'll send another mail on this topic.
nvdbleek: For the other elements
ili wants to make it more visible
... Would it be enough if we bold the deprecated word?
unl: I will have a look at other W3C specs
ACTION unl To have a look at how other specifications style deprecated elements/attributes and come with a proposal for styling in the XForms Sepc
<trackbot> Created ACTION-1936 - Have a look at how other specifications style deprecated elements/attributes and come with a proposal for styling in the XForms Spec [on Ulrich Nicolas Lissé - due 2013-03-13].
http://lists.w3.org/Archives/Public/public-forms/2013Jan/0027.html
nvdbleek: Discussed this a couple of calls ago, we thought of maybe dropping the script elements
alain: I think it is useful in actions
ebruchez: We found it very useful for javascript, and also use it to call XPath functions with side effects.. But we have a proposal to do it with an action element with an extra type attribute on the action element
nvdbleek: Script has the benefit of being an element in HTML
ebruchez: How do you do this in xsltforms?
<ebruchez> <xf:load resource="javascript:foo()"/>
alain: Not yet possible xsltforms, but it is useful in the future
nvdbleek: what happens if there is exception in javascript? Do you wrap it in an XForms element.
ebruchez: currently we
don't
... The load hack is only useful for short expressions. But it
supports AVT's in the script we don't have a way to pass in
parameters
nvdbleek: if we allow the script element as a child of function then you have a way to pass in parameters
ebruchez: then you call the xpath function to invoke it?
<ebruchez> http://wiki.orbeon.com/forms/projects/client-side-api-for-custom-javascript-widgets
nvdbleek: Yes, oh but we don't have a way to invoke an Xpath function in an action. We also said that our functions shouldn't have side effects and certainly not change instance data
ebruchez: A plain script element is useful, but is missing some features like passing in parameters, getting the value back, ...
alain: I think XQuery is the only good solution for this
nvdbleek: I don't think a lot of XForms implementations have XQuery support
alain: I don't know if the script element should be in the XForms 2.0 time frame
nvdbleek: maybe postpone it
... Uli what do you think about it?
unl: I don't think we should postpone it, my only concern was the name of the script related events
ebruchez: the super long event name should go
unl: I was thinking of a compute exception with context info
nvdbleek: until now the compute exception is only send in binding expressions
unl: What do you send when an action fails
<ebruchez> http://wiki.orbeon.com/forms/welcome/xforms-error-handling
ebruchez: We implemented something new, because we want to recover from failing actions
nvdbleek: ebruchez we have an xxforms-action-error
ebruchez: We stopped sending the
compute and binding-exception because they are stopping
processing and don't make sense for us
... We dispatch those events, and they don't stop XForms
processing
unl: That is not compliant to the spec then?
ebruchez: you are correct
nvdbleek: what do you think of an xforms-action-error event instead of the two events?
unl: I would reuse an existing event
ebruchez: any xpath expression
can fail (with a dynamic expression)
... for the spec when xpath expression fails a compute
exception occurs and processing stops
... but that is wrong
nvdbleek: Agreed, but reworking that will be a lot of work and not feasible for XForms 2.0
unl: Aggreed
ebruchez: Adding a general event like xforms-action-error and currently only use it for very specific cases, but broaden it in the future
<ebruchez> xforms-action-error
ebruchez: I find the name compute-exception not a clear name for me for an action that fails
unl: is it fatal?
ebruchez: It is an error, so it would not stop processing
unl: We should review all actions
ebruchez: We have for example the
load action 'If the link traversal fails, then an
implementation-specific means of conveying the link traversal
failure occurs.'
... we only have a dozen actions, and not a lot can fail I
think, beside xpath errors, and other just don't do anything on
failure (e.g.: toggle with invalid ID doesn't do
anything)
... xforms-action-error is a good name
nvdbleek: I also think that the name is better, and future proof
unl: are we with enough people to
make resolution
... Could you send a proposal before
ACTION nvdbleek to write a proposal for the xforms-action-error event instead of the current script exceptions.
<trackbot> Created ACTION-1937 - Write a proposal for the xforms-action-error event instead of the current script exceptions. [on Nick Van Den Bleeken - due 2013-03-13].
tarckbot, end meeting
trackbot, end meeting
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/depricated/deprecated/ Succeeded: s/Sepc/Spec/ Found Scribe: nick Found ScribeNick: nvdbleek Default Present: nvdbleek, ebruchez, unl, [IPcaller] Present: nvdbleek ebruchez unl [IPcaller] Regrets: Steven Agenda: http://lists.w3.org/Archives/Public/public-forms/2013Mar/0001.html Found Date: 06 Mar 2013 Guessing minutes URL: http://www.w3.org/2013/03/06-forms-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]