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

John,

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

If I had the choice of an XForms implementation supporting xf:model/@src or xi:include/@xpointer then I’d go with the latter because that is far more flexible and useful throughout the model and the view portions of the app and promotes other, existing, XML technologies over ad hoc language extensions.

Also, the XInclude option has the distinct advantage of making the developer responsible for any ID fix-up that’s required, and I think that’s how it should be.


Regards

Philip Fennell
Consultant

Mark Logic Corporation
www.marklogic.com<http://www.marklogic.com/>

E-mail: philip.fennell@marklogic.com<mailto:philip.fennell@marklogic.com>
Mobile: +44 (0)7824 830 866

[cid:image001.jpg@01CADD52.B6C96870]<http://www.marklogic.com/UserConference2010/>



From: John Boyer [mailto:boyerj@ca.ibm.com]
Sent: Friday, April 16, 2010 12:17 AM
To: Philip Fennell
Cc: Nick Van den Bleeken; public-forms@w3.org
Subject: 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.

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




From:

Philip Fennell <Philip.Fennell@marklogic.com>

To:

John Boyer/CanWest/IBM@IBMCA, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>

Cc:

"public-forms@w3.org" <public-forms@w3.org>

Date:

04/15/2010 03:10 PM

Subject:

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


________________________________



John,

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.


Regards

Philip Fennell
Consultant

Mark Logic Corporation
www.marklogic.com<http://www.marklogic.com/>

E-mail: philip.fennell@marklogic.com<mailto:philip.fennell@marklogic.com>
Mobile: +44 (0)7824 830 866

[cid:image001.jpg@01CADD52.B6C96870]<http://www.marklogic.com/UserConference2010/>



From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: Monday, April 12, 2010 10:01 PM
To: Nick Van den Bleeken
Cc: public-forms@w3.org
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 importation.

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 group.

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.

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


From:

Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>

To:

John Boyer/CanWest/IBM@IBMCA, "public-forms@w3.org" <public-forms@w3.org>

Date:

04/09/2010 12:13 AM

Subject:

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




________________________________




John,

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 document).

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.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com <mailto:nick.van.den.bleeken@inventivegroup.com>
http://www.inventivedesigners.com<http://www.inventivedesigners.com/>
Linked in<http://be.linkedin.com/in/nvdbleek>

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On Behalf Of John Boyer
Sent: vrijdag 9 april 2010 2:54
To: public-forms@w3.org
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].

[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


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



________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


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