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

Hi Philip,

From the "putting your money where your mouth is" perspective, I'd have no 
choice but to concur since we built the Form Parts feature in a framework 
(i.e. Designer tooling/transformational) way rather than as a language 
(i.e. run-time) feature.

I think the working group generally agrees that run-time fix ups are 
daunting.  I imagine Erik/Orbeon would have more to say about it.

But this takes us back to the simpler issue of model/@src.  The 
communication started from a drill down in which many of us, including 
you, have indicated we want something like model/@src, but when we look 
under the covers we become hard pressed to identify a significant 
advantage that it provides, and it isn't until you do something like 
either Form Parts or Orbeon's XBL-based components that you get a 
significant advantage over what we have now.

So, the question is, what could you do with model/@src that can't already 
be done with, say, XInclude?

FWIW, I am especially worried about ID fix-ups given the number of places 
where we can now obtain the ID from data.  I think the idea is just plain 
not going to work out due to the case subelement of toggle, the control 
subelement of setfocus, etc.

John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab


Blog RSS feed:

Philip Fennell <>
John Boyer/CanWest/IBM@IBMCA, Nick Van den Bleeken 
"" <>
04/15/2010 03:10 PM
RE: Regarding import of external content, some info on our "Form  Parts" 

With respect to the generalized component import issue, is there not a 
risk that we are blurring the line between XForms language features and 
XForms frameworks features. As a language, XForms is rather odd in that it 
comes in two separate, but dependant, parts and uses a host document to 
support them both, a kind of three-way symbiotic relationship. I can see 
how re-usable form components are a good idea in and of themselves but the 
whole business of defining an import that can/should only be declared in 
one place but must have an outcome in two places is rather, if not too, 
complex for what is otherwise a straight forward and elegant language.
The concept of Xf:model/@src is a good idea and one that I have wished for 
in the past.
Where I’m currently generating XForms from XML Schema, I’m using XProc to 
orchestrate the transformations and will probably end up with a step that 
delivers the model and view components on separate ‘model’ and ‘view’ 
result ports, respectively, and then use subsequent steps to insert those 
results into a host application XHTML document. That is probably why I see 
the multi-destination import as a framework feature more than a language 
feature because it seem easier to solve that way. The amount of ‘fix-up’ 
required to do the same amount of work automatically would be quite 
daunting and would probably render any additional bindings after the act 
of importation impossible to manage/work as you’d have no idea what the 
fix-up has done to your model, instance and bind IDs.
Philip Fennell
Mark Logic Corporation
Mobile: +44 (0)7824 830 866 

From: [] On 
Behalf Of John Boyer
Sent: Monday, April 12, 2010 10:01 PM
To: Nick Van den Bleeken
Subject: RE: Regarding import of external content, some info on our "Form 
Parts" feature

Hi Nick, 

Yes I agree that we are also essentially saying that simple external model 
is not enough to solve all of the problems faced by our customers, who 
seem to need a more generalized "custom subform component" capability. 

Still, external model seemed like a step in the right direction, ignoring 
what we currently do with "Form Parts", even though it doesn't solve the 
problem of combining UI and model declarations into a single reusable 
component.  It seemed like we might at least be able to get some 
instances, submissions and binds that would enable importation of web 
service definitions, for example. 

In this regard, it makes sense to talk about "Form Parts" as another 
instance-- not the only one-- of a technology that would be both capable 
of and *likely* to be used as a substitute for simple external model 

The fact that both "Form Parts" at design time or XBL at run-time could 
also be used to create generalized custom components does not detract from 
the fact that we've seen two categorically different approaches that have 
arisen that would both benefit from having the one standardized way of 
doing the import, even if that import did not scale up to the case of 
generalized custom components.  Whether it has enough value or not, 
without also getting generalized custom components, is of course up to the 

Meanwhile, the reason why a simple external model import cannot scale up 
to generalized custom components seems to be clear also, by looking at 
both the XBL approach and the "Form Parts" approach.  In both cases, two 
different techniques are used to ensure that both UI and model content are 
added to the importing form.   In both cases, the exact point of injection 
into the UI is, and has to be, identified.  The injection point into the 
model does not seem to be so important and is not identifed by either 
approach.  Any kind of "model import" that turned into "subform import" 
would need to add a way to indicate where in the UI should be injected the 
UI portion of the subform. 

John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab


Blog RSS feed:

Nick Van den Bleeken <> 
John Boyer/CanWest/IBM@IBMCA, "" <> 
04/09/2010 12:13 AM 
RE: Regarding import of external content, some info on our "Form Parts" 

Correct me if I’m wrong, but I see this as custom components. There is a 
bit of tweak that the ‘components’ are resolved at runtime, but this can 
be just how your implementation resolves the components (it only looks in 
the ‘archive’ created for the form document, the document itself could 
also be seen as an ‘archive’ if you want, you can refer inside the 
For me it seems very close to what is solved in Orbeon by their custom 
components implementation based on XBL. Erik is better placed to elaborate 
on this, but what I see are: a binding site in the form (both data and 
UI), local models, probably some kind of communication between the main 
form and the ‘sub form’ using events (you didn’t spell this out, but I 
think you will have it or will need it in the future). Orbeon’s solution 
is also a bit more generic that it doesn’t acts as a single group, they 
can have multiple data bindings to the custom control (again, Erik correct 
me if I’m wrong). 
We are hitting more and more cases in our company that require a ‘custom 
component’/’reusable sub-form’ solution. I believe that this is something 
that should have a high importance on our roadmap, but I don’t think that 
external models and ‘custom components’/’reusable sub-forms’ are the same 
thing. External models should be the smaller feature of the two. 
Nick Van den Bleeken 
R&D Manager 
Phone: +32 3 821 01 70 
Office Fax: +32 3 821 01 71 
Linked in 
From: [] On 
Behalf Of John Boyer
Sent: vrijdag 9 april 2010 2:54
Subject: 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]. 


John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab


Blog RSS feed: 

This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 

Inventive Designers' Email Disclaimer: 

This message has been scanned for viruses and 
dangerous content, and is believed to be clean. 

Received on Thursday, 15 April 2010 23:17:14 UTC