- 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>. https://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_instance_Element 1) <instance src="foo"> <data xmlns=""><a>0</a></data> </instance> @src is used. If it fails, an exception is dispatched. <instance resource="foo"> <data xmlns=""><a>0</a></data> </instance> The inline content is used, @resource is ignored. 2) <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 ignored. 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 content: <instance src="saved-data.xml"> <data xmlns=""> ... initial data ... </data> </instance> ) Steven
Received on Wednesday, 8 October 2014 17:39:13 UTC