Regarding import of external content, some info on our "Form Parts" feature

Dear Forms WG,

As part of the work of determining how to approach the import of external 
content, I have been asked to provide some technical information on our 
"Form Parts" feature, which is related in that it does call for 
importation of XForms content into a larger XForms, but is not strictly 
related to the simple use of a src attribute on model or otherwise.

The IBM Lotus Forms team is currently implementing a feature called "Form 
Parts", and a fair bit of the functionality is currently available in our 
latest "Tech Preview". 

The "Form Parts" feature allows users of our Form Designer environment to 
create reusable form fragments that may be consumed by any number of form 
templates in a form collection. 
The Design environment can understand any number of Form Parts, and the 
form author can update any number of form parts before requested to update 
the form templates that use the updated form parts.

The form templates themselves contain the content of each Form Part they 
consume plus an indication of where that content came from.  The indicator 
allows us to do the updating, but having the form part content in the form 
template means that the form template is always ready to be published to 
the web without a "compile" step.  In other words, the compile step is 
loaded onto form part updates rather than as a prerequisite to someone 
trying to use the form.  Furthermore, it should be clear that the form 
template is always ready to be used by a run-time XForms processor without 
it having to load externally referenced content.

In our solution, a "Form Part" can have multiple "components".  In our 
Tech Preview, you get one component that logically maps to the content of 
an xforms:group element.  In other words, the component is designed to 
allow the form author to define a set of user interface elements that are 
reusable in multiple forms.

When a form author drags and drops such a "Form Part" on the Design 
canvas, they effectively get a copy of the user interface contained by the 
main component of the Form Part.  By default, our Design environment 
automatically generates the underlying XForms instance data model for a 
form, so a data layer for this UI is automatically created.  However, the 
design environment is also responsive to more advanced form authors that 
have designed their own data layer, e.g. according to an XML Schema.  The 
form part drag and drop opereration automatically brings up a design-time 
dialog that allows the form author to create a mapping of the UI 
components onto the existing data model in the form to which the Form Part 
content is being added.  The form author can click OK without creating a 
mapping, in which case a data instance for the UI is automatically 
generated into the form as mentioned above.

The work we are currently undertaking on this "Form Parts" feature 
recognizes that a form fundamentally has two components, the UI part and 
the data model part.  So, we are currently enabling our Form Parts to have 
a second component that contains xforms:model content.  Thus, when the 
form authors drags and drops a form part onto the design canvas, the UI 
component would be added by adding an xforms:group to the UI layer, and 
any xfoms:binds or other model content would be added to the default 
xforms:model of the form.  This allows us to have a reusable form part 
that expresses both UI as well as constraints, calculates, etc on the data 
collected by that UI.

So, in a way, this solution could be seen as another, perhaps easier, way 
to deal with the larger problem of form composition.  At the run-time 
level, we seem to always think about subforms and try to solve the problem 
of data communication between a subform and the form that contains it. The 
"Form Parts" solution instead does an injection of markup into two 
non-continuous locations within a document.  In this way, it is also not 
like an XInclude or the use of a simple src attribute.  Finally, by virtue 
of being a Design time mechanism, issues related to ID conflicts are 
sorted out before the form ever hits the run-time.

The downside of this approach is that it assumes a Design experience 
distinct from the run-time, whereas the W3C track record on Design 
environments rarely if ever gets beyond a text editor. 

So, even if we were to have a run-time mechanism, my ideal world would be 
a customized solution that could inject content into at least two 
non-continuous parts of a form.  Furthermore, despite the fact that our 
*current* system is based on the Design time, I do see value in moving 
what we have into a run-time solution because I think it would help to 
create more interesting "Interactive Web Documents".  But that is another 
topic with prerequisite reading at [1].

[1] http://portal.acm.org/citation.cfm?id=1600193.1600226

Cheers,
John M. Boyer, Ph.D.
STSM, Lotus Forms
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