AVTs and deprecated child elements

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].

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: 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].