Re: xforms-link-exception (and connection to event() function)

Hi Joern and Erik,

We discussed this issue on today's telecon.

I don't think I could produce a link for you offhand, but I know this 
issue came up many years ago, and it sort of fell by the wayside due to 
other larger issues for which there were no workarounds.  The workaround 
often used (for better or worse) is to invoke a submission rather than 
using an src, precisely to allow error recovery.  I'm not saying that's 
great, just that's why this issue fell by the wayside.

Anyway, it does seem more logical for the failure of an src to act more 
like an xforms-submit-error rather than an exception.  To that end, in the 
XForms 1.2 instance data module, we're going to have link failure result 
in dispatching an xforms-link-error to the instance element.  It will be 
possible to stop the propagation of this error or otherwise indicate. Then 
in the model module, we can say that the xforms-link-exception will be 
dispatched if an xforms-link-error bubbles up to it.  This would give you 
the ability to shut off the exception by stopping the error.

This doesn't help you for 1.1, of course.  We have been deliberately vague 
in the past about what actions work prior to the completion of the 
model-construct event.  I would say you are not likely to get 
interoperability on *any* of the setvalue invocations that happen prior to 
completion of model-construct.  In the past I think we've said that only 
static message actions would work, and that the ref attribute on message 
could not be guaranteed to resolve correctly prior to completion of 
model-construct.

The catching/handling of xforms-link-exception (and all the exceptions) 
has largely been associated with debugging only.  The link exception on 
instance is a left over from many years ago when there was only one 
instance in a model, and it never got updated to reflect the fact that 
multiple instances means that the failure of the src attribute should be 
recoverable.

One thing that would help is if the event() function could return the 
target of the event, so that for debugging purposes you could at least 
find out which instance failed to load.  But, adding insult to injury, 
having common event information available through the event function is 
also something that will only be available in XForms 1.2.  However, some 
implementations will lead the spec, and since this is debugging 
information, you could choose to use those implementations when debugging.

That appears to be the best we're going to be able to do right now...

Best regards,
John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Erik Bruchez <ebruchez@orbeon.com>
To:
www-forms@w3.org
Date:
08/19/2008 04:26 PM
Subject:
Re: xforms-link-exception




Joern,

I guess we should discuss this during the next telecon.

In general, regarding the actions that halt processing, I agree that 
in some cases at least we should allow the form author to prevent the 
execution of the default action (i.e. prevent stopping the processing).

This in particular applies to the evaluation of XPath expressions. 
Expressions in actions, in particular, should be recoverable. FWIW 
back in the days I sent more details about the confusion of xforms- 
compute-exception and xforms-binding-exception [1].

-Erik

[1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0059.html

On Aug 13, 2008, at 3:45 PM, Joern Turner wrote:

>
> Please consider the following snippet:
>
> <xf:model id="model">
>            <xf:setvalue ev:event="xforms-link-exception"
> ref="instance('test')/foo" value="'bar'"/>
>            <xf:instance id="test" xmlns="">
>                <data>
>                    <foo></foo>
>                </data>
>            </xf:instance>
>            <xf:instance id="instance" xmlns="" 
> src="nonExistingResource.xml"/>
> </xf:model>
>
> Under 3.3.2 i read:
> "If the initial instance data is given by a link (from src or
> resource), then the instance data is formed by creating an XPath data
> model of the linked resource. If the link cannot be traversed, then
> processing halts after dispatching an xforms-link-exception with a
> resource-uri of the link that failed."
>
> As processing halts after the xforms-link-exception is the setvalue
> action executed (resulting in instance 'test' having a node foo with
> value 'bar') or not? As processing is stopped anyway you can argue
> that this makes no difference as you can't do anything with that value
> anyway. Do i miss something?
>
> What would be the correct (conformant) behavior for an 
> implementation here?
>
> Second question:
> isn't there a good reason why the above maybe shouldn't work without
> interrupting processing (non-fatal exception) as it is the case with a
> xforms-submit-error?
>
> Imagine a form calling a remote service with a @src URI - but it
> cannot always foreseen if the service is always available. If the
> above would work without stopping the 'test' instance could give
> explanations to the user about the problem and maybe continue
> processing on an alternative branch.
>
> The whole thing becomes even a bit trickier if you put it like this:
> <xf:model id="model">
>            <xf:setvalue ev:event="xforms-link-exception"
> ref="instance('test')/foo" value="'bar'"/>
>
>            <xf:instance id="instance" xmlns="" 
> src="nonExistingResource.xml"/>
>            <xf:instance id="test" xmlns="">
>                <data>
>                    <foo></foo>
>                </data>
>            </xf:instance>
> </xf:model>
>
> If the link-exception is dispatched right after initialization of
> first instance failed there would be no way to execute the setvalue
> action as the target instance have not yet been created.
>
> On the other hand from an author's point of view i can imagine the
> following being desirable:
> <xf:model id="model">
>            <xf:instance id="instance" xmlns=""
> src="URI_of_firstInsecureServiceProvider-1"/>
>            <xf:instance id="test"
> src="URI_of_firstInsecureServiceProvider-2" xmlns=""/>
> </xf:model>
> If the link-exception wouldn't be fatal you'd be able to implement a
> fall-through this simple.
>
> To be most valuable the dispatching of the link-exception should be
> deferred until all instances have initialized (or tried to do so).
> Then a meaningful reaction for the user would be possible:
> <xf:model id="model">
>            <xf:setvalue ev:event="xforms-link-exception"
> ref="instance('test')/foo" value="concat('Service at:' +
> 'event("resource-uri")' + "failed to respond"/>
>
>            <xf:instance id="instance" xmlns="" 
> src="nonExistingResource.xml"/>
>            <xf:instance id="test" xmlns="">
>                <data>
>                    <foo></foo>
>                </data>
>            </xf:instance>
> </xf:model>
>
> Thanks,
>
> Joern
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/