Any ZIP package is a flat collection of files and, eventually, folders. Files can refer to not-explicitly-defined folders by just mentioned them in their names. For example, “xl/worksheets/sheet1.xml” is a valid file name and no declaration is required for “xl” nor “worksheets” folders.

It is easy to extend XForms to allow ZIP packages editing:

First of all, mime types can be used to distinguish them. The default one is “application/zip” but there are many others such as “application/vnd.openxmlformats-officedocument.spreadsheetml.sheet” for Excel 2007. So, a mime type value can be used in a submission to indicate that a ZIP package will be sent or received.

An instance with such a mediatype can be initialized with @src but, if it is not possible, it has to be created with a temporary document. It means that when replacing an instance at the end of a submission, the mediatype is changed accordingly.

But, to access data in a ZIP package, a file name has to be provided. It implies that the instance() is to be called and that there must be an extra optional parameter for this file name. Adding a second parameter for the specific mediatype of the file might be helpful too. For example, to access the value of the B3 cell, the XPath expression will be: instance(‘myworkbook’,'xl/worksheets/sheet1.xml’)/ss:sheetData/ss:row[@r = 3]/ss:c[@r = 'B3']/ss:is/ss:t

This is enough for extracting XML data from any ZIP package and modify it before submitting the modified ZIP package.

This has been experimented in XSLTForms with well-known zip_inflate and zip_deflate Javascript functions written by Masanao Izumo (http://www.onicos.com/staff/iz/amuse/javascript/expert/). For example, a form written with XSLTForms can be initialized with data coming from an Office file, it can modify it directly in the browser without the Microsoft Office Suite being installed locally.

For better Excel editing experience, XSLTForms uses XSLT to convert any shared string in an Excel sheet into an inline string. It allows to directly access and modify cell content in the same file. If formulas might have to be recalculated in the spreadsheets, instead of having to press Ctrl+Alt+F9, the simplest way is to add the attribute fullCalcOnLoad to the calcPr element in the workbook.xml document with “1″ as value (this can easily be done with an insert action).

It is also easier to initialize the cells to be set with a dummy value because empty cells are not present in the XML serialization. A work instance with bindings to fill the Excel sheet is also a light way to design the form.

Full ZIP packages management would require to define extra actions to remove/add a file. But it is already possible to create a template ZIP package with the exact number of required files (for Excel, each sheet is represented a distinct file, itself being listed in other files).

Here is the example for this: http://www.agencexml.com/xsltforms/Workbook-Editor.xml

The snapshots of the drafts for review by WG and community can be found at http://www.w3.org/MarkUp/Forms/Drafts/ (including a diff compared to the previous WD).

All comments gratefully received!

Try clicking, double clicking, mouse wheel moves. I commented out mouse-move events, since so many of them are generated.

You can also see shift/alt/ctrl/meta keys working on mouse-down events (they work on other events, but I only show them on mouse-down).

At the hack I proposed an electronic forms based application specifically for pre-operative assessments (essentially a set of questions designed to ascertain the background health and associated anaesthetic risk for patient scheduled for surgery). As I had previous experience of XForms I wanted to use XForms to create the front end of the application. The main requirements I had were a good fit for XForms – see below:

• The form should be as intuitive as possible for the patients:
• This meant that the form should be based upon clearly laid out sections – in this case I used the <xf:switch/> statement to present different sections.
• Questions posed to the patient depend on their previous answers – here I used a mixture of <xf:group ref=”.[conditional statement]“> and <xf:bind id=”SomeId” relevant=”conditional statement”/> <xf:select1 bind=”SomeId”/>
• Errors on the form needed to be clearly highlighted to the user with associated help/hint text – a feature directly supported by XForms
• The form needed to be “pretty” – Not being a UI expert I used Twitter’s bootstrap to help style the form. This is still work in progress and I did need to figure out a few things but the integration so far with XSLTForms has not too been too painful.
• Options for select controls need to be sourced externally.
• In the current version of forms4health I have used a simple XML data models.
• In a full blown application these may be more complex in be sourced from an standalone terminology server.
• Either way the use of <xf:model/> and the <xf:itemset/> allows this information to be losley coupled to the form.
• The results of the form need to be sent/saved as XML
• The healthcare administrator “booking” the assessment has a choice of PDF or XML as the output of the form submission - here I used XForms to send the XML to a background Java servlet that either forwarded the XML directly or created a PDF via XSL:FO / FOP.
• Where XML is requested this is typically for integration with the healthcare institution’s own systems, however the specific XML may vary depending on healthcare facility. This implies the need for lose coupling between the UI and the data – The MVC architecture of XForms allows this coupling to be defined declaratively.
• The form needs to be available on a variety of platforms
• In theory this is well aligned with XForms however (and I may be wrong) for now I think the majority of XForms applications are still being developed as web-sites/embeded in HTML.  I used XSTLForms as this supports a large number of web browsers, however I have pre-processed (transformed) the xml files to html to ensure as wide a compatibility as possible (you will be able to see the difference between http://www.forms4health.com/registration.html and http://www.forms4health.com/registration.xml if you do ”view source”)
• The form and associated functionality needed to be developed quickly
• The declarative nature of XForms allowed us to build upon the excellent foundation provided by XForms to rapidly generate working applications

Overall XForms was great for being able to quickly create a very usable application with relatively simple/lightweight backend logic to produce a workable application. I am hoping the demo site will provide enough inspiration for an NHS (or other healthcare provider) organisation to sponsor the development of a fully functioning service.

Authors with XForms usually use a workaround based on as many group controls and XPath predicates as necessary, as in <group ref=”mycontext[mycondition_1]“>…</group><group ref=”mycontext[mycondition_2]…</group>…

There is still a restriction because of the use of the id attribute: a case as to be unique in a form because it is identified with its id attribute value.

For big forms, for subforms, for switchs, the id attribute is too restrictive. The new var element is using the name attribute instead. Next version of XForms could benefit in getting ride of the id attribute and replacing it with the name attribute. XSLTForms is already generating missing ids according to the position of the element in the tree and ids could be generated from names with a similar approach without a big effort.

What do you think?

Thanks!

-Alain

Community Group members are encouraged to keep this up-to-date, and improve the entries for their own implementations.

New releases and upgrade releases announced in the news (though not daily releases) should be moved to the top of the list at the time of announcement so that the most active implementations bubble to the top of the list over time.

1. A wiki.
2. An irc channel [irc://irc.w3.org:6665/#xformsusers] If you don’t have an IRC user agent, you can always use http://irc.w3.org/ .
3. Mailing lists (public-xformsusers@w3.org and public-xformsusers-contrib@w3.org).

You are encouraged to join: note that you don’t have to be a member of W3C to join, but you do have to agree to an IPR statement.

The initial aims of the group are:

1. To encourage users of XForms to bring their discussions here, for discussion of techniques, usage, and suggestions to improvements and additions to the language.
2. Allow people to contribute to the XForms test suite.
3. Allow people to maintain the list of implementations.
4. Allow the XForms Working Group to give updates on XForms 2.
5. Move the XForms+HTML Note/Rec document over to xformsusers to incubate it.

This last is a note documenting how you combine XForms with (X)HTML; it will be converted to wiki markup and put on the Community Group’s wiki, allowing group members to contribute to it.

This is of course only an initial list of aims, brainstormed by the Working Group. It is up to the Users Group to further develop this list.

Currently the group has no chair. The group will decide on a chair once it has reached sufficient size.

For more information about Community Groups, see Community and Business Groups.