[23 July 2012]
The other day, I posted a kind of design challenge for XForms: what is the best way to provide an editing interface for tightly constrained, arbitrarily recursive structures like those found in arithmetic or logical expressions or in languages like XPath or programming languages?
Another topic comes up from time to time as a challenge for XForms interfaces: mixed content.
One view, which seems to be reasonably widely held, is that the best way to handle mixed content in XForms is to provide some sort of ‘rich-text’ editor like the tools provided by some libraries for editing HTML documents in the browser. (I put scare quotes around ‘rich text’ in that phrase because HTML-encoded text doesn’t seem particularly rich by some standards.) Many (all?) of the major XForms implementations have rich-text editors of one kind or another tha work this way.
I think such widgets work well for some applications. But they are almost never what I think I want when I think about handling mixed content in applications I’d like to build with XForms. I think I can distinguish two cases, or classes of cases.
The first case is similar to that handled by the existing rich-text widgets: allow the user to edit a paragraph or a series of paragraphs, and to mark phrases within the paragraphs with phrase-level markup. In this use case, I think I want several things (some of which may be achievable with current extension widgets, with a little work or a lot):
- I’d like to be able to specify, for each individual instantiation of the control, which phrase-level elements are allowed. (E.g.: bold and italic here, italic-only over there.)
- I’d like to be able to specify elements in vocabularies other than HTML. (E.g. TEI, TEI Lite, DocBook, JATS, …)
- I’d like the editing widget to allow crystals as sub-structures. (By crystals I mean sub-elements with fixed internal structure; they may float in a sort of text soup, but they retain their own internal structure while doing so. In XHTML, lists [ordered, unordered, and definition-] are a simple example.)
- If the editor automatically interprets hard returns as marking paragraph boundaries (as some do), I’d like to be able to specify what the paragraph element is called. And ideally I’d like to allow more than one such top-level element, so the user can use the widget to create a sequence of (for example)
In the second case (or class of cases), I want to be able to display mixed-content elements in a normal read-only way, with flowed text and font shifts and so on, and I want to be able to allow the user to edit selected aspects of the material, but not all. For example:
- In some cases I’d want the user to be able to edit the
keyattribute on the
placeelements in the text, but I would like it to be impossible for the user to change the text of the paragraph.
- In some cases I’d like to allow the user to change element types (changing a
place, or vice versa), and in other cases not.
- Often I’d like to allow the user to select a contiguous sequence of characters in the paragraph and say that they should be tagged as
- And then there is the scenario Henry Thompson once used to introduce me to the idea of padded-cell editors: we are preparing a corpus for linguistic research and we have a provisional segmentation of the text into sentences (or sentence-like objects). We want an interface that will allow a human being to review the segmentation and correct it. They should be able to open a document, split existing
selements, join adjacent
selements, save, or quit without saving.
The same questions apply here as for the earlier thought experiment:
1 Are there any really good ways to implement interfaces of this class today (in XForms 1.1, or with extensions in existing XForms implementations)?
2 What are the possible ways of doing this kind of thing (or: any of these kinds of things) today? (In the absence of a really good to do it, any technically feasible way is worth knowing about; it’s better than nothing.) Extra credit, as always, for sound analysis of the pros and cons and for pointers to examples to illustrate the techniques.
3 What changes to XForms might allow implementations of a future version of the spec to handle this class of problem (more) easily?