The organizers of Balisage have announced that the topic of the 2013 pre-conference symposium on 5 August will be Native XML User Interfaces. I will be chairing the symposium this year.

Any project that uses XML intensively will occasionally find it handy to provide specialized interfaces for specific tasks. Historical documentary editions, for example, typically work through any document being published several times: once to transcribe it, several times to proofread it, once to identify points to be annotated, once (or more) to insert the annotation, once for indexing, and so on and so forth. Producers of language corpora similarly work in multiple passes: once to identify sentence boundaries in the transcriptions (possibly by automated means), once to check and correct the sentence boundaries, once to align the sentence boundaries with the sound data, and so on and so forth.

But how?

We can train all our users to use a general-purpose XML editor, but as Henry Thompson pointed out to me some time ago, one problem with that approach is that the person doing the correction of the sentence boundary markup probably should not be changing (on purpose or by accident) the transcription of the data. If you get bored by a tedious task while working with a general-purpose editor, there is essentially no limit to the damage you could do to the document (on purpose or by accident).

Each of these specialized tasks could benefit from having a specialized user interface. But how?

We can write an editor from scratch (if we have a good user interface library and sufficient time on our hands). Java and C++ and Objective-C all have well known user-interface toolkits; for many other languages, the user-interface toolkits are probably less well known (and possibly less mature) but they are surely there. Henry Thompson and his colleagues in Edinburgh did a lot of work in this vein using Python to implement what they called padded-cell editors.

We don’t have to write the editor from scratch: we can adapt a general-purpose open-source editor (if it’s in a language we are comfortable working in).

We can customize a general-purpose editor (if it has a good customization interface and we know how to use it). I believe a lot of organizations have commissioned customized versions of SGML and XML editors over the years; at one point, SoftQuad had a commercial product (Sculptor) whose purpose was to allow the extension and customization of Author/Editor using Scheme as the customization language.

We can write Javascript that runs in the user’s browser (if we are prepared to stock up on aspirin).

We can write elaborate user interfaces with XSLT 2.0 in the browser, using Michael Kay’s Saxon-CE.

We can write XQuery in the browser using either a plugin or an XQuery engine compiled into Javascript. (I am not sure I can say for certain how many variants of XQuery in the browser there are; I believe the initial implementations were as plugins for IE and Firefox, but the current version appears to be deployed in Javascript.)

We can write XForms, which have the advantage of being strictly declarative and (for many developers) of allowing much of the work to be done using familiar XHTML, CSS, and XPath idioms.

How well do these different approaches work? What is the experience of people and projects who have used them? And how is a person to choose rationally among these many possibilities? What are the relative strengths and weaknesses of the various options? What are the prospects for future developments in this area? These are among the questions I expect attendees at the symposium will get a better grip on.

(As any reader of this blog knows, I think XForms has a compelling story to tell for anyone interested in user interfaces to XML data, so I expect XForms to be prominent in the symposium program. But I’m interested in any and all possible solutions to the problem of developing good user interfaces for XML processing, so we are casting our nets as widely as we can in defining the topic of the symposium.)

A couple of weeks ago, I took some time to explore the use of sub-forms in XSLTForms, as a possible way to speed up an XForm I had written that was a little slower than I would have liked.

The short version of the story is: WOW! Well worth learning to use.

To understand the longer version, dear Reader, you should know that one of the most common performance issues in serious uses of XForms is that forms sometimes slow down when the instance documents they are working on get big. I assume this is because browsers are profligate with resources, perhaps because some aspects of the XML DOM force them to be, perhaps because profligacy pays off most of the time. But I can’t say I really know for sure.

So one of the things that sophisticated users of XForms spend a lot of time on is finding ways to avoid loading all the instance documents at once. (This is a lot easier when you’re using an XML database as a back end, of course.) Another is finding ways to avoid loading all of the form at once; that is where sub-forms come in. The word doesn’t occur in the XForms 1.1 spec, but a number of implementations provide experimental support for sub-forms as an extension. The basic idea is that whenever certain events occur in a form, the XForms implementation will load some appropriate resource specifying some XForms widgets and bind them into the current form. When other events occur, those widgets will be unloaded again. I first saw this in a demo on the BetterFORM site a few years ago, but I see that Mark Birbeck was talking about this as long ago as 2006. And more recently, Alain Couthures has added sub-form support to XSLTForms.

Making my form use a sub-form turned out to be simpler than I had feared. I already had a full working version of the form, and it was clear which part of it I wanted to load and unload dynamically. What I had to do was just:

Move the part of the form that should load dynamically (which I’ll now call the subform) into a separate XHTML + XForms document. Give it a simple XForms model, and check to make sure that it works by itself. (It doesn’t actually have to work by itself, but it’s helpful to know the subform hasn’t got fatal errors on its own.)

In the main form, put an XForms xf:group where the sub-form used to be; give that group an ID.

Associate a load action with the appropriate event. (In my form, I had a trigger that toggled a switch, exposing the read/write view of some material. The sub-form now has that read-write view, and the trigger now throws a load action.)

Associate an unload action with another appropriate event. (In my form, this was the trigger that formerly toggled the switch back to the read-only view.)

In principle, that’s it, though I had to fiddle a bit to make everything work right. In particular I ended up adding a ref="." attribute to the outermost xf:group in the sub-form. I’m not yet sure just when this is necessary and when it’s not.

The simple example of sub-forms loading on the XSLTForms web site is very helpful here: it’s a very simple example and illustrates all the moving parts clearly. (But you will need to read the source and think about what is going on; there isn’t a lot of commentary or documentation around.)

What really impressed me were the effects of this change on the performance of the form.

Since sub-form support was added fairly recently to XSLTForms, I had to upgrade from an older release of XSLTForms to the recent release 1.0RC. I did some fairly tedious timings before and after I made the change, and I can say with some evidence that this change alone gave my form about a 25% increase in speed. Then I made the changes mentioned above, to use sub-forms. That gave me another 25% increase, so that on almost all actions version 1.0RC using sub-forms was about twice as fast as the older version Beta3 using a monolithic form.

Moral 1: If you are having performance issues with an XForm, and you can see how you might use a sub-form, then try it.

Moral 2: If you are having performance issues with an XForm, and you are using XSLTForms, then try moving to 1.0RC even if you can’t see how to use a sub-form in your context. Alain Couthures has done a lot of work on performance, and it clearly helps.

Bear in mind that the precise syntax and semantics of sub-forms are a topic of discussion in the XForms working group, so (a) they are subject to change, and (b) the working group is open to suggestions for making sub-forms (or any other part of XForms) work better.

XML for digital librarians

Recently the organizers of the ACM / IEEE-CS 2012 Joint Conference on Digital Libraries asked me to teach a pre-conference tutorial on “Making the most of XML in Digital Libraries”; JCDL will be hosted by George Washington University in Washington, DC, this year.

The tutorial description runs something like this:

The Extensible Markup Language (XML) was designed to help make electronic information device- and application-independent and thus give that information a longer useful lifetime. XML is thus a natural tool for constructing digital libraries. But where exactly does XML fit into the conceptual framework of digital libraries? Where can XML and related technologies help achieve DL goals?

This tutorial will provide participants with an introduction to basic concepts of XML and a DL-oriented overview of XML and related technologies (XML, XPath, XSLT, XQuery, the XML information set, XDM, XForms, XProc, and many more). The intent is to show how XML can be used to help digital libraries achieve their goals and to enable participants to know which XML technologies are most relevant for the work they are involved with.

The JCDL site doesn’t have a detailed schedule yet, so I don’t know the exact time and date of this tutorial.

XForms for XML users

I’ve also arranged with Mulberry Technologies of Rockville, Maryland, to use their training facilities to offer two two-day training courses immediately before and after the JCDL conference, so that people traveling to DC for JCDL can extend their trip at one or both ends to attend the courses.

One course provides an Introduction to XForms for XML users, covering a technology with huge (and largely unrecognized) potential for users of XML. XForms is built around the model / view / controller idiom, with a collection of XML documents playing the role of the model, and with the view represented (in most uses of XForms) by an XHTML document. The end result is that a few lines of XHTML, XForms, and CSS can suffice to build user interfaces that would take hundreds of lines of Javascript and thousands or tens of thousands of lines of Java or a similar language. XForms makes it feasible to write project-specific, workflow-specific, even task-specific XML editors; no serious XML project should be without XForms capabilities.

The XForms course will be held just before JCDL, on Friday and Saturday 8 and 9 June.

XQuery for documents

The other course provides an introduction to XQuery for documents. Much of the interest in XQuery has come from database vendors and database users, and not surprisingly much of the public discussion of XQuery has focused on the kinds of problems familiar to users of database management systems. Those who use XML for natural-language documents have, I think, sometimes gotten the impression that XQuery must be aimed primarily at other kinds of XML and other kinds of people. This course is designed to introduce XQuery in a way that underscores its relevance to the human-readable documents that are historically the core use case for XML, with examples that assume an interest in documents rather than an interest in database management systems. This course will be held just following JCDL, on Friday and Saturday 16 and 16 June.

Further information on the two Black Mesa Technologies courses is on the Black Mesa Technologies site at the pages indicated.

The conference has used printed feedback forms in the past, and the online forms ask essentially the same questions as the paper forms have always asked. Overall, what’s your impression of the registration process? the materials (the on-site guide to the conference, the proceedings), etc. etc. For each question, the paper forms ask for an overall judgement (Good, Okay, Bad) and provide a space for comments. In recent years, the space for the overall judgement has taken the form of three small graphic images, showing smiling, neutral, and frowning faces:

A first version of the form

The XML document created by the form has a sequence of elements for the various topics: registration, materials, presentations, etc. Each covers one question in the form. For most questions, the element has an attribute named overall to record the user’s overall judgement of how well we did in that area, and its contents include any comments the user types into the comments field. (A few questions have a more complex XML representation, which will be discussed in separate posts.) If you would like to see the XML produced by the form in full detail, you can: go to the overview page, select the form you want to examine, optionally fill it in with some sample data, and select the Show XML button at the bottom of the page.

A straightforward translation into XForms of the question about registration would use a select1 element with the three values Good, Okay, and Bad, and an associated comments field, like this:

A first enhancement: smiling faces

The first obvious enhancement is to follow the paper form in using images of smiling and frowning faces for the various values. A few hours on the Web turned up a large number of public-domain clip-art sites, many with sets of widgets including smiling and frowning faces. It turns out that there are also smiling-face and frowning-face characters in Unicode (in the Miscellaneous Symbols block U+2600 to U+26FF), but no corresponding neutral face. And nowadays there is an entire block of Unicode emoticons (U+1F600 to U+1F64F). I was tempted by the Unicode characters, but ultimately decided that on my screen, at least, they were too hard to read clearly. So eventually I settled on a set of icons from a clip-art site.

Integrating the smiley images into the labels is simple: just embed an img element in the label, as shown here.

To make it easier to see what the images are saying, the full form includes a large version of the images at the top, with explanatory labels. (This version of the form actually uses two different sets of clip-art images, so I could look at each of them in context and decide which one I wanted to use.)

A second enhancement: clicking on the images

The overall Good / Okay / Bad ratings still take up a lot of screen real estate, though.

And what I really wanted was not just to use the images as part of the labels for the radio buttons, but to have an even simpler interface: ideally, I wanted just to show the three icons and let the user click on them to specify that they thought things were good, back, or okay. (There is a certain amount of danger in this way of thinking: part of the point of XForms is to provide device-independent forms that might be rendered in different ways on different devices: getting really specific about details like this may interfere with device independence.)

This can be achieved in XForms, too. After some experimentation, I ended up a method of handling this that looks like this in the browser: a large image showing the current rating for the topic, and three small images (but larger than the images in the earlier versions of the form) for changing the rating.

The large display is handled with a sequence of xf:group elements, each of which contains an img element and each of which binds to the overall rating for a given topic if that rating has the particular value associated with the image.

So the big image for the registration topic will show a smiling face if the overall attribute on the registration element has the value good, and a frowning face if it has the value bad, and so on.

The value of the overall attribute could be set by the select1 elements shown above, but in the final version we used a set of XForms triggers (user-activatable controls — on a laptop screen these are typically buttons) labeled with the images for the values:

As you can see, each trigger contains a label element which in turn contains the image, and a setvalue element which specifies the action to be run when the trigger is activated. In each case, the action is to set the value of the overall attribute to the appropriate value.

The group as a whole, the large image, and the set of three triggers are each wrapped in an XHTML div element with a different class value, to make it easier to style the display appropriately using CSS.

With XForms, it was easy to get a first working version of the form, much easier than it has ever been for me to get an equivalently complex form running in straight HTML forms, with its model of form content as a flat undifferentiated sequence of attribute-value pairs. And with XForms and CSS, it was (relatively) easy to change the look and to replace the radio buttons of the first version of the form with image-labeled buttons. Working with Javascript libraries has never been anything like this straightforward for me.

In a previous post, I mentioned the evaluation forms we put together for the Balisage conference last year, using XForms. This is the first of a series of posts discussing some aspects of the design and development in more detail.

One of the first requirements for these forms was that if at all possible they should have the same look and feel as the pages on the main conference site. In XForms, this turns out to be remarkably simple: XForms is designed to be styled using whatever styling mechanisms are usual for the host document vocabulary. In the case of XForms in XHTML, running in a Web browser, that means the form can be styled using CSS. And because the form is embedded in a normal XHTML document, any necessary logos or graphic apparatus can be embedded in the normal way.

[The xhtml:dummy attribute is a work-around that helps XSLTForms compensate for the bug in Mozilla’s XSLT implementation: Mozilla does not support the XPath namespace axis, so the only way XSLTForms can discover what namespaces are in scope is to walk around the tree collecting namespace bindings from elements and attributes in the document. The value of the attribute doesn’t matter; I use a value that reminds me of why I have to have the attribute there in the first place.]

They use the same overall document structure as the main Balisage pages: three divs of class header, mainbody, and footer, respectively,
with the second in turn divided into navbar and body.

[Note: strictly speaking, as those who go and look at the HTML coding of the main Balisage site will discover, this is not “the same overall document structure” as the main Balisage pages. For reasons I won’t go into here, the main Balisage site uses XHTML tables to lay out the pages. I usually try to avoid tables, so the forms use div elements with CSS style rules to govern the layout. Apart from avoiding invidious comments from those who disapprove of using tables for layout purposes, I find the documents somewhat easier to navigate and edit this way.]

They embed the appropriate material. The header embeds the Balisage logo:

It turns out to be psychologically helpful to have the form appropriately styled, both for me in developing it and for those whom I ask to review draft versions of the form. It’s so helpful, in fact, that one of the first things I do, in developing a form for a particular site, is to create an XForms template for the site, with

the namespace declarations for XHTML, XForms, XML Events, XSD, and any other namespaces that may be needed (extra namespace declarations cause no trouble, and missing ones cause a lot);

a link to the standard site stylesheet, or (if the standard site stylesheet uses tables) an equivalent stylesheet that provides the correct look

the high-level document structure needed by the site stylesheet

dummy headings and body text, using Greeking (‘lorem ipsum …’)

XForms is designed to allow forms to be integrated nicely into a site’s normal look and feel; the template makes it easier to do that consistently across all the forms used on a given site.

In recent years I’ve spent a fair amount of time telling people about XForms as a method for making special-purpose XML editors. From time to time people ask me what sorts of things it’s possible to do in XForms, and by implication what sorts of things don’t fit very well in XForms. It’s a good question, but I don’t know a good way to answer in words. The only way I know to answer is to show some examples of things done in XForms.

In that connection, perhaps it’s worth while to point to an XForms application I put together last year for Balisage 2011. The organizers of Balisage place great weight on feedback from participants, and we’ve always used paper feedback forms distributed to participants on the last day of the conference. Paper forms have the drawback of only being in one place at any given time, and since the organizers don’t all work in the same location, most of the organizers only got a chance to look at the feedback forms on the afternoon after the conference ended, before everyone went home. (Yes, we could have had them photocopied, but we never got around to it.) So last year I suggested we do electronic forms, in addition to the paper forms (which we entered into the electronic system by hand, afterwards).

The forms we ended up with (all pointed to from http://balisage.blackmesatech.com/) illustrate one kind of application it’s easy to do in XForms. To answer, up front, a frequently asked question: no, they don’t do anything you couldn’t do in Javascript or HTML Forms plus a little bit of Javascript. (Javascript is a Turing-complete language; how could any technology do anything that could not, in principle, be done in Javascript? Asking if XForms can do things you couldn’t do in Javascript is like asking whether the XForms spec contains a refutation of Gödel’s Theorem.) Doing them in XForms made these forms easier to develop and debug, and XForms provide XML output, which means the forms are easier to summarize and analyse than they would otherwise be. I have written conventional HTML forms interfaces to generate XML, so I know it’s possible. I also know it’s tedious; XForms is much much more convenient.

These feedback forms posed a few interesting design challenges, and I went through several iterations, bugging my colleagues on the organizing committee for feedback until I suspect most of them were heartily sick of the whole thing. The various alternatives are worth some discussion; in subsequent posts I’ll discuss the issues and some of the alternative ways of handling them in XForms.

The organization of the material will be substantially the same as in the earlier iterations of the course. And the rationale for XForms, as I understand it, remains as described in an earlier post to this blog; the course is directed to users of XML who want to use XForms to work with XML representations of information.

In case it matters to potential attendees, I’ll point out that the course will occur just before the Digital Humanities 2011 conference down the road in Palo Alto.

The course will cover the XForms processing model, the treatment of simple values and the creation of simple structures, repetitions of the same element, sequences of heterogeneous elements, and techniques for using XForms for complex forms, dynamic interfaces, and multilingual interfaces. It’s based on the one-and-a-half day course given last November at the TEI Members Meeting in Zadar, Croatia, which (judging by the participants’ evaluations) was a success.

XForms have great potential for individuals, projects, and organizations using XML seriously: XForms is based on the model / view / controller idiom, and the model in question is represented by a set of XML documents. That means that you can use XForms to create specialized editing interfaces for XML documents, which exploit the styling and interface capabilities of the host language (typically XHTML) and can also exploit your knowledge of your own data and requirements.

Some people have built more or less general-purpose XML editors for specific vocabularies using XForms. That works, I think, more or less, though in many cases I think you’ll get better results acquiring a good XML editor and learning to use it. XForms really shines, I think, in the creation of ad hoc special-purpose editors for the performance of specialized tasks.

In many projects, XML documents are created and refined in multiple specialized passes. In a historical documentary edition, the document will be transcribed, then proofread and corrected in multiple passes performed by different people, or pairs of people. Another pass over the document will mark places where annotations are needed and note the information needed to write those annotations. (“Who is this person mentioned here? Need a short biographical note.”) And so on.

In a language corpus, an automated process may have attempted to mark sentence boundaries, and a human reviewer may be assigned to correct them; the only things that reviewer is supposed to do are open the document, split all of the s elements where the software missed a sentence boundary, join adjacent s elements wherever the software was wrong in thinking it had found a sentence boundary, save the document, and quit. If you undertake this task in a full XML editor, and you get bored and lose concentration, there is essentially no limit to the amount of damage you could accidentally do to the data by mistake. What is needed for situations like this is what Henry Thompson of the University of Edinburgh calls ‘padded-cell editors’ — editors in which you cannot do all that much damage, precisely because they are not full-featured general-purpose editors. Because they allow the user to do only a few things, padded-cell editors can have simpler user interfaces and be easier to learn than general-purpose editors.

The construction of padded-cell editors has always been a complicated and expensive task; it’s going to take thousands, or tens of thousands, of lines of Java or Objective C or Python to build one, even if you have a reasonably good library to use. With XForms, the high-level abstractions and the declarative nature of the specification make it possible to do roughly the same work with much less code: a few hundred lines of XHTML, CSS, and XForms-specific markup.

This is why I think XForms has a place in the toolkit of any project or organization making serious use of XML. And, coincidentally, it may be a reason you, dear reader, or someone you know may want to attend this XForms course.

(Oh, yes, one more thing: we have set up an email announcement list for people who want to receive email notification of this and other courses organized or taught by Black Mesa Technologies; a sign-up page is available.)