W3C home > Mailing lists > Public > public-forms@w3.org > October 2014

Re: instance @src and @resource

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 8 Oct 2014 10:37:42 -0700
To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
Cc: public-forms@w3.org
Message-ID: <OFF0257A38.8D8B96C8-ON88257D6B.005E7303-88257D6B.0060D60A@ca.ibm.com>
Hi Steven,

The background here is that XForms 1.0 had a src attribute on instance 
that had the specific particular intention of providing a URL for instance 
data rather than using inline data. So, the primary use case was src 
*instead* of inline content, and the way implementations were implementing 
it caused there to be an error. At the time, implementations didn't 
uniformly seem able to avoid the error if an author provided inline 
content to use as backup, so the group decided that that was not going to 
be a supporting use case.

Then, in XForms 1.1, resource attribute was added to somewhat solve the 
use case of using a URL as a backup to having no inline content (rather 
than having it be resolved first, before inline content).  That use case 
is most appropriate to document-centric use cases, like ODF and IBM Forms. 
 The document may represent a multiparty contract or agreement.  The form 
document flows through a multistage business process. In the start state, 
no users have yet contributed data, so the instance element does not 
contain an XML tree, and the resource attribute is exercised to obtain the 
initial start-state data structure that will drive the business process. 
This data structure is then placed into the document, so when it is 
submitted back into the business process, it now contains the data 
structure inline in the instance element, including any data added by the 
first user. When it is stored and later delivered to a second user in the 
business process, the inline data is used in lieu of resolving the 
resource attribute.

This design is also helpful during form authoring because it allows the 
form template (document-centric or not) to be worked on and stored 
separately from the data layer.

It's worth noting that it was a deliberate intention at the time to make 
the addition in XForms 1.1 without perturbing XForms 1.0 compatibility. 
This is another reason why the src attribute and the resource attribute 
don't interact with each other and are not intended to be used together. 
But the high order bit remained, at the time, that some implementation of 
src unavoidably produced the exception without ability to move on, neither 
to inline content nor its fallback resource attribute.  I believe this is 
because the src attribute was meant to be aligned with how HTML operates 
the src attribute.

Best regards, 
John M. Boyer, Ph.D.
Chief Architect, Watson Linguistic Products
IBM Distinguished Engineer & IBM Master Inventor
@johnboyerphd | boyerj@ca.ibm.com

From:   "Steven Pemberton" <Steven.Pemberton@cwi.nl>
To:     public-forms@w3.org, 
Date:   10/08/2014 04:06 AM
Subject:        instance @src and @resource

I'm still a little concerned about the difference between @src and 
@resource on <instance>.

<instance src="foo">
    <data xmlns=""><a>0</a></data>

@src is used. If it fails, an exception is dispatched.

<instance resource="foo">
    <data xmlns=""><a>0</a></data>

The inline content is used, @resource is ignored.

<instance src="foo"/>
@src is used. If it fails, an exception is dispatched.

<instance resource="foo"/>
@resource is used. If it fails, an exception is dispatched.

<instance src="foo" resource="foo"/>
@src is used. If it fails, an exception is dispatched. @resource is 

So who can explain to me the point?

(On a related note, it might be useful to let the inline content be a 
fallback for @src, and only dispatch an exception if there is no inline 

                 <instance src="saved-data.xml">
                                 <data xmlns="">
                                                 ... initial data ...

Received on Wednesday, 8 October 2014 17:39:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:10 UTC