Lobbying for features

This is still very much in the making; the section on XPointer has been moved to a separate page; comments are welcome.
Piotr 21:30, 2 November 2009 (EST)

Although it is a firmly established standard by now, the TEI has to constantly evolve for basically three reasons: it needs to improve, it needs to expand (think e.g. ontology markup or modern corpus formats), and it needs to keep up with the evolving technology of its medium of expression, i.e., XML. This means that, however hard we try, there will always be a risk of a clash between the needs of TEI users and the broadly understood technological limitations, such as the issue of compliance with the ever-developing basic standards (think XPath 1.0/2.0 and XPointer for addressing; recall also the move from SGML/P3 to XML/P4-P5), or the numerous tools used for authoring, processing, querying and rendering.

We are a large and active community, a well-mixed blend of mostly Digital Humanities and (generally speaking) Computer Science professionals, with ties both to academia and software industry, and as such, we are potentially quite a force, a pressure group, if only our needs as TEI-ers can be identified and our efforts towards reaching them coordinated. And the power is not only in the numbers, but also, fundamentally, in the achievements of the TEI: from the widespread use of the standard in digitalizing manuscripts and literary works, through corpus/dictionary encoding, to the TEI's strong connection to Web/XML standards, such as XLink or ISO 24610-1:2006 (feature structure encoding).

This article is targeted primarily at those members of the community who are not necessarily deeply involved into the technicalities of XML, but are nevertheless willing to help push the standard ahead by shooing some low-level technical monstrosities out of its way.

Complain all you want, but then ACT

From time to time, we complain on the TEI-L about the insufficient software support for various devices/techniques suggested in the Guidelines (mostly, this pertains to XML manipulation or visualization). Complaining in a closed group is rarely successful, however, the outcome being usually of two kinds: either disappointment followed by surrender, or investment of one's own time and effort in eliminating the obstacle, at the cost of the project at hand and possibly duplicating the work of others. The third way, however, is for the closed group to channel its pressure towards external, specialized groups, e.g. software developers or standards bodies.

Why should these external groups care about the needs of TEI-ers? As usual, mostly because they can benefit from satisfying these needs -- but they need to learn about this opportunity first. Here's a list of the factors that might be relevant in such cases:

• if there is an articulated need for feature X in our community, many of us are going to use it
• because we are a strong community, the number of users of feature X is potentially large
• software developers and standards need users to survive: users test the development versions, create feedback, suggest ideas, and spread the word
• if, therefore, the particular software package supports the features we need, a lot of mouths are going to praise it and make others use it
• once some of us start using X, it becomes a standard feature, recommended by the Guidelines and practice, and thus more of us may start using it (at this point, loop two bullets up)
• and because of the above-mentioned past achievements of the TEI, it is quite possible that the currently undersupported features (think e.g. of advanced XPointer), will turn out to be indispensable in the near future, if their usefulness can be demonstrated not only in theory, but also in actual use; the one who supports it early reaps most of the harvest (think Saxon, always at the front with respect to XSLT standards support).

Of course, part of the trick is in knowing which external groups to turn to and how to bring the issue at hand to their attention and flash the potential benefits in their eyes. In other words, when a problem is signalled at TEI-L that comes from outside the standard itself, instead of kludgeing a temporary solution in your markup or writing to all possible mailing lists with "XML" in their name, it would be good to know where exactly the little lever responsible for the problem is. If a hundred hands push it, the effect may be quite impressive.

Act how?

How can our community exert influence on outside groups? Several ways come to mind, and the list below won't certainly be exhaustive, feel welcome to discuss others.

Firstly, perhaps the most trivial way to get things done is to talk about them to people who can help. Whether we are teachers/researchers, librarians or software architects -- all of us have contacts or ways of getting in contact with people in charge of software packages or participants in standards organizations (and the TEI has had a few, still does). Let's not underestimate the power of a friendly conversation over lunch or during a conference coffee break ;-)

Secondly, sometimes we happen to have a brilliant student who nevertheless needs a suggestion for his or her diploma work. If they happen to be CS students, why not have them work on an extra module to (or a modification of) an open-source package that will support the functionality the TEI needs. A job like that may actually be much more satisfying for the student than building some obscure program/package merely in order to demonstrate that they can. In fact, some software projects may designate some areas for supervised student work -- as is the case of Mozilla Education project. Note that even the philologists among us have colleagues at Computer Science departments who may be interested in this.

Finally, and this is what I want to focus on here, there is something all of us can do as users of various kinds of software: exert pressure on the developers by indicating to them how desperately a given feature or bug-fix is needed. Let me call this lobbying for features.

Lobbying for features

Most projects have components designed for gathering user feedback. At this point, many readers are going to think of tedious writing of bug reports or feature requests, and they will partially be right -- after all, if you want something done, then at least make sure to signal it to the developers in such a way as to make the report easy to find and the work on it easy to track and test. However, there is also a related activity that costs much less effort: we can indirectly indicate to the developers that the number of users affected by the given problem is high, by voting and/or adding our e-mail addresses to the CC list for the report.

Let me illustrate this on the example of Bugzilla -- a well-known and popular bug-tracking system. In his recent blog entry, "Firefox and namespace nodes: an open plea", Michael Sperberg-McQueen asks his readers for help in lobbying, by voting on bug report number 94270 to be moved higher in the priority of Mozilla developers. You can see there both the CC list on the right and the number of votes on the left of it. (Incidentally, note also that the report is keyworded as a 'student-project', which means exactly what you think.)

Another good example is Brett Zamir's campaign for external entities.

from this point on, sketchy notes follow, to be tidied up some day...

Stuff worth linking to, perhaps:

• https://bugzilla.mozilla.org/show_bug.cgi?id=22942 "(entities) Load external DTDs (entity/entities) (local and remote) if a pref is set"
• Henry S. Thompson's mail to xml-dev on the above
• http://www.w3.org/Bugs/Public/query.cgi -- W3C bugzilla

List of projects and places where lobbying is needed

This is to be the climax of this article: I would like to put here a list of places where members of the TEI community can go and e.g. cast their votes or help in bug triaging, etc.

• Brett Zamir's campaign for external entities.
• the article on XPointer contains an excerpt from the list of bugs in xmllint that need your votes to die
• another issue concerns xmllint's treatment of the xml:lang attribute; see Stuart Yeats' bug report on this (and do at least consider voting, i.e. adding your address to the CC list)
• Sourceforge is voting over fine-grained permissions in SVN repositories. This can be useful not only for the main TEI project at Sourceforge, but also for other TEI-related projects -- it has the potential to give your project more dynamics, when you can hire developers for specific parts of the repository and not worry about the other parts. You need an SF account to vote there. But an SF account is also useful for discussing or requesting features of the TEI project, so don't hesitate :-)

Have a look at a story of another, successful, two-person campaign for "TEI" as an official Sourceforge data category.

---

If for some reason you do not want to use the discussion page, I welcome comments by e-mail. Piotr 23:35, 30 October 2009 (EDT)