TEI Council Meeting

Editorial support

SR outlined the major tasks of the editorial support group in Oxford and the nature of its relationship to Council:

• Monitor TEI-L and email to editors@tei-c.org in order to identify feature requests and bug reports for the Guidelines. Triage these and present them to Council for decisions where necessary.
• Silently handle minor fixes and corrections, and prepare Guidelines releases every 6 months.
• Maintain the tools that are considered to be TEI Consortium deliverables, such as the XSLT stylesheets and Roma. (There are other tools for which it is less clear whether they are to be seen as TEI-endorsed.)

In summary, the main job of the editorial support group is to be sure that TEI deliverables are maintained.

LR notes that this represents a real change. Editors are no longer taking decisions unilaterally, but rather based on exchanges with Council. He suggests regular reports to Council from the support group. (Discussion: is anything needed beyond the changelogs kept automatically on SourceForge? Consensus: periodic summaries of significant changes would be useful in addition.) LB will produce a summary of all SourceForge changes a week before every Council meeting.

This agenda item concluded with some discussion of how the Oxford group would insure redundancy and continuity. SR noted that the editorial tasks can be handled by any one of SR, LB, and JC. As for interaction with Council and representation at Council meetings, consensus was that ordinarily one representative from the Oxford group will attend meetings as a non-elected member, but Council may invite more at its discretion.

Role of SIGs and working groups

Discussion of this agenda item covered four main topics: (1) the nature of the continuum between Special Interest Groups (SIGs) and chartered TEI workgroups; (2) the relation of SIGs and workgroups to Council; (3) procedures for insuring SIGs remain viable, and discontinuing moribund SIGs when necessary; and (4) strategies for encouraging a wide range of activity. DO notes that the Board (??) is interested in breaking down the fixed distinction between SIGs and workgroups in the interest of flexibility in meeting needs.

1. The main difference between a SIG and a workgroup is that the latter is formed to complete a particular task (with defined deliverables) and is chartered until the completion of that task. LB notes that it has always been the case that if a formal task proposal emerges from a SIG, Council may charter a workgroup. DO notes that certain small tasks may be assigned to a SIG without requiring a formal charter. Asked whether TEI has a budget to encourage such small targeted tasks, DO replied that although the budget needs to be formalized there would seem to be some funds available. DO report back on funding situation for small SIG tasks.

2. Previously, when a workgroup was chartered its chair became a non-elected member of Council (??). Going forward, individual Council members will serve as mentors/liaisons to both workgroups and SIGs. The head of a workgroup may still be invited to Council meetings as needed. In summary: Council will formally charter workgroups and specific SIG tasks, and assign a Council liaison in each case. We also have a formal SIG coordinator appointed from the Board (currently Susan Schreibman).

3. Workgroups have a specific charter, but SIGs are centered around a mission statement representing shared interest. Thus there is the problem that a SIG may become moribund. How do we get rid of deadwood (LR)? The Board has the authority to disband them, but we should focus on support: SIG leaders will now have a term of office, assuring turnover. Council will assist the SIG coordinator in encouraging the activities of SIGs. LR notes that one of Council’s roles is to insure that SIGs and workgroups have complementary, non-overlapping roles. EP says that the required SIG reports are another important way for Council to keep track of SIG activity.

4. We agree that it is in the TEI’s interest to encourage a wide range of activities, from formally chartered workgroups through SIGs to more loosely affiliated interest groups. An advantage of TEI branding of activities is that we give credit to people who contribute to the community (DO). SIGs will not always center around a specific shared task; as JC notes, some SIGs exist mainly for community building rather than to provide deliverables.

We concluded with some discussion of TEI-related activity that is not formally affiliated with the TEI Consortium. DO suggested that we need to do more to capture contributions from the community at large, but it was noted that some projects, e.g. TEI by Example, want to be autonomous. We agreed that our outreach doesn’t have to be colonial.

Procedures for handling Guidelines feature requests and bugs

LR summarizes our basic procedures: everyday bugs (fixing typos and small technical errors) will be handled by the Oxford editorial support group. The Oxford group will also gather feature requests and bug reports from TEI-L, email, and elsewhere. These will be presented to Council for consideration on a regular basis.

JC and SR agree that Council members should be encouraged to submit feature requests and bug reports as well. There are some concerns about the ease of use of the Sourceforge tracking system and the fact that (as SR pointed out) there is not full overlap between the group of people who can assign and close SourceForge tasks and the group of developers with write-access to the Subversion repository. Should we split up the SourceForge projects? After discussion, consensus was that the SourceForge system has worked without serious problems and should not be subject to major changes at this time.

Outstanding Sourceforge feature requests and bugs

A major portion of our time on Day 1 was spent discussing outstanding bugs and feature requests on SourceForge. The items and outcomes are summarized in a separate document, , which is hereby included by reference in these minutes.

New chapter proposal on rendering

We next considered the proposal from Brett Zamir to add to the Guidelines a chapter

.

After some discussion, Council reached a consensus that the draft document is not suitable as a formal chapter of the Guidelines, largely because the technologies and procedures used for output rendering change frequently and are not under the control of the TEI Consortium (e.g., XSLT processors, CSS standards, etc.). However, we agreed that users of the TEI, particularly new users, are typically interested in questions of output: I have tagged it, now how do I show it? Therefore we should make a point of incorporating some of the suggestions from the draft chapter in other material, such as the proposed

document (q.v. below).

TEI-METS

[JW was originally scheduled to report on the status of TEI and METS, but we deemed that this ground had been covered sufficiently by the paper that he had presented at the Wednesday workshop.]

document proposal

Peter Boot had previously suggested that Council discuss the creation of an introductory document on using the TEI Guidelines, sponsored by the TEI and produced as an activity led by Council. PB had volunteered to chair this activity.

In PB’s view, this document would be a lowest common denominator, assuming as a typical reader perhaps a graduate student working on a text who wants to make it available using TEI. It would not re-do our

but would be a new document conceived as a standalone resource that could be read by itself as a complete text, something one could “read on the train”, although it would contain many pointers (and links, in its Web-based version) to other material. It would be clearly visible as a central TEI document and should in LR’s words be a flagship entry point to the TEI. As an analogue, Edward Vanhoutte’s in (19.1, 2004) has been cited as one of LLC‘s most frequently downloaded articles. Consensus: all agreed that we want to move forward with this project. In DO’s words, this is as central a task for Council as Guidelines. A book not of similar complexity, but of similar deliberation.

Some further discussion focused on issues of content and audience. PB’s original proposal had suggested targeting examples at Windows users, but Council consensus was that an official TEI document cannot be platform-specific. LB notes that when introductory TEI documents were first proposed, the assumption was that a primer works best when addressed to members of a specific discipline; he advocates careful thought about the scope of this publication and its target audience. Consensus emerged around LR’s observation that the document should have sufficient material to be suitable for students as well as specialist researchers. DS suggested we might survey potential readers ahead of time on topics they’d like to see addressed; DO recommended that we circulate a first draft online for feedback.

We agreed with LB that this document must look different from existing introductory guides and tutorials; simplicity should be a key goal, with short, precise sections and word limits. (LR suggests a maximum length equivalent to about 50 printed pages.)

PB will go ahead and take charge of this project with assistance from Council, coming up with a list of contributors (after we issue a call for volunteers) and returning with a fuller proposal based on response. We will aim for a first draft suitable for feedback for the Members’ Meeting in November 2008.

Proposal for SIG on correspondence

LR and DS presented the proposal for a Special Interest Group on correspondence that came to use from Peter Stadler and Joachim Veit of Paderborn University. DS noted that previously two major initiatives have developed TEI extensions designed to handle epistolary documents and related genres, the Model Editions Partnership and DALF; he advised that any new efforts toward TEI customizations for use with correspondence should look closely at the document analyses and solutions devised by those groups. (DS noted that in the American context on which the MEP concentrated, correspondence was one of a number of genres included in documentary editions (e.g. the

), and had originally proposed that the SIG’s mission might include this larger context; but Council consensus was that the specific focus on correspondence/epistles is an appropriate scope.)

LR stated that the SIG proposers should address four points: (1) the scope of the SIG (just personal correspondence or epistles, or more?); (2) examples of encoded material; (3) networking the various groups and initiatives interested in correspondence, beyond the context of German-speaking musical historians; (4) the object of the SIG as a TEI-chartered group.

Council agreed that the purpose of this SIG should not be the creation of a Guidelines chapter; rather, a document on encoding certain types of documents (perhaps included proposed TEI customizations). If this work is done well enough, we can brand it. In any event, Council and the SIG liaison assigned to the group should monitor their work closely. DS will submit an outline to the Paderborn researchers expressing our interest in the proposal and asking them to address LR’s four points.

OpenOffice and Microsoft Word conversions

This agenda item was to address the tools provided on Sourceforge for converting between TEI-XML and OpenOffice, and related MS Word conversion. SR began by noting that although the OpenOffice stylesheets are hosted on the TEI Sourceforge site, there has never been a suggestion that they are an official TEI activity; they are an individual contribution from SR. Nor is he actively developing Word stylesheets (though this will change if the ISO project goes forward). There are really two purposes for conversion to and from word processing formats: its an easy way to write angle brackets, and an easier way to print documents than using TEI-XML (usually). Consensus was that the TEI does not want to own these tools for now, as that imposes a requirement to maintain them.

Work on TEI (X)HTML and PDF stylesheets

A related item is the XSLT stylesheets which we do formally provide as a tool for transforming TEI documents to HTML, LaTeX, and XSL-FO. Discussion here focused on how these might be improved and/or extended.

As a preliminary caveat, however, SR noted that we don’t want to imply there’s a default way of rendering everything. JW observed that we already have a problem with TEI users encoding to match the stylesheet—i.e., choosing tagging on the basis of how it will be displayed via our XSLT. DO agrees that we don’t want to suggest there is a single canonical way of representing TEI, but having stylesheets tailored for standard use cases would be helpful; can our stylesheets be made more modular? AC cited as a sample use case a stylesheet using the transcr module that would align transcription with original image. Or (LR) the Correspondence SIG could work on improving stylesheet rendering for epistolary texts. TMB noted that her users particularly like a service that allows them to submit a small TEI-XML file and get back an HTML. Question: should we provide complete examples of encoding and rendering? EP points out that we long ago made a decision not to do this because it would appear too normative.

Consensus: Although we don’t want to provide tools per se, stylesheets are important to our mission. Providing and/or disseminating useful ones should be considered part of our educational and outreach mission. DO will produce several example texts and SR will provide some sample renderings using them.

Creation of element examples in the Guidelines

This agenda item involved the examples of tagging that are included in the Guidelines (and other TEI documents).

JC proposed that we might want to come up with a new framework for examples. Examples are found in multiple places and are not identified by language. Sometimes examples of one element provide good examples of another one but there is no way to find them. Can we internationalize examples and improve indexing and retrieval of them?

There followed some technical discussion of approaches we might take, e.g. extending the content model of elementSpec so that it could point to more examples; using XInclude to pull in examples from elsewhere; using XPointer to point to examples in alternate languages; using standoff markup…

In the meantime, however, we need to improve the current coverage of examples for elements in the Guidelines. SR estimates that about 10% of TEI elements in the reference section do not carry examples, and sets off to determine which these are in real time as the meeting proceeds. Everyone: Council members are each assigned a module and will create examples for elements lacking them from Sebastian’s final list, with assignments as follows. Examples to be sent to LB; for newly authored examples, provide a bibliographic citation. (Also, check the “Note” for each element, if one exists, to be sure its text remains correct for the latest release of P5.)

• analysis: DO
• core: DS
• dictionaries: PS
• figures: JW
• gaiji: GB
• header: DO
• iso-fs: LR
• linking: GB
• msdescription: JC
• namesdates: AC
• nets: LR
• spoken: PB
• tagdocs: TMB
• textcrit: EP
• textstructure: PB
• transcr: EP

As a final point, PB observed that the content model (in the “Declaration” section of the element reference) is too complicated, and would prefer a prose description. LB points out that this would not be maintainable. Consensus: do not pursue.

Internationalization

SR reports that over that past two years, 5 or 6 groups have been working on translation of the reference portions of the Guidelines. Chinese, French, German, Spanish, Japanese, and Italian are being done manually. Within the next few weeks the first 5 languages should be complete (?? which?).

Oxford is testing automated translation software from Systran that is being evaluated as a way of translating additional languages (as a first pass; human editors would need to clean up the translations). We might be able to get another 3 or 4 languages done this year using it. For example, a native Portuguese speaker estimated it might take about 3 days to clean up the automatic Portuguese translation.

Question: how do we maintain the translations? The Systran license is for one year only. Consensus: community-based translation is the only viable way of maintaining translations, by having the user communities take responsibility for them.

ISO proposal

(SR) Last autumn the ISO put out a call for bids on preparing a document template and schema for authoring future ISO standards documents. Oxford U. responded with a proposal for doing it in TEI. An ISO committee visited Oxford and the proposal is in the process of being accepted; we are now waiting for formal confirmation. The ISO would contract with Oxford to: draw up an ODD representation of an ISO standards document (including SVG and MathML). Transforms from MS Word to TEI would be assigned to someone at Brigham Young University. Copyright for the ODD would be given to the TEI Consortium, to issue under an open-source license.

We agreed that if this agreement is reached, one benefit to the TEI community would be our branding of the standard. SR feels that it will be some time before documents are actually authored in TEI (rather than converted from MS Word), but LB notes that it will be more likely for documents that define new schemas.

We then discussed whether to seek ISO status for the ODD schema specification. Although ODD is currently used mainly within the TEI community, SR reports that one W3C project is using it. LR outlines 3 possible options for proceeding: (1) start working on it as a continuation of ISO-doc project, and take a proposal to the ISO technical management board; (2): submit ODD as a candidate on a fast-track procedure as a generic standard for schema specification (but a problem is that it would have to go into the same generic IT committee that considered the MS Office XML format; (3) reduce scope and visibility by going to a committee like TC37, so as to be seen as a candidate specification for language resource applications.

LB raises a concern about whether ODD is yet stable enough to proceed. Also, will people object that ODD is just an expanded schema language that does nothing which W3C XML Schema cannot do? (SR notes that any consideration of ODD would logically belong in JTC 1/SC 34 – Document Description and Processing Languages, where NVDL and RELAX NG live.)

Is this worth our time and resources? Is it within our mission? Consensus: yes, this would bring benefits to the current TEI community and would serve as outreach to the larger XML community. It would return benefits to us if more native TEI applications result, along with a more stable ODD language. We will begin exploring this with the relevant people within the standards community. LR will talk to his contacts.

TEI Tite

DO reported on the status of TEI Tite and the study underway headed by John Unsworth and Perry Trolard to project the demand and uses for the TEI Tite customization intended to be used for digitizing printed material such as monographs in bulk quantities. The study will also explore including access to a consortial vendor agreement as a TEI Member benefit. Both potential clients and keyboarding vendors will be surveyed as part of the study.

All agreed that there needs to be closer integration of the work on Tite into Council activities, and improved lines of communication. DO will try to set up a conference call with John Unsworth, to include PS, JW, DS, and LR.

ENRICH project

JC reports on the ENRICH Project (European Networking Resources and Information concerning Cultural Heritage), a two-year project that LB and SR have previously worked with and that JC will be in the future. The aim is twofold: to aggregate metadata for medieval manuscripts in a single portal, and to have the archives standardize on TEI P5 as a data format. The Czech Republic is committed to long-term maintenance of the project. (Note that Manuscriptorium, the portal site, is a commercial enterprise; this is not an open-access project. However, the ENRICH ODD and conversion XSLT stylesheets for Master2TEI will be made publicly available under an open source license.)