[19 February 2013]
Any project that uses XML intensively will occasionally find it handy to provide specialized interfaces for specific tasks. Historical documentary editions, sickness for example, ed 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.
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 elaborate user interfaces with XSLT 2.0 in the browser, using Michael Kay’s Saxon-CE.
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.)
I hope to see you there!