[tei-council] Comments on "Getting Started" proposal

[David Sewell]

Peter, I think the proposed outline of contents is excellent. It moves 
from simple/general to more specific and advanced topics in the 
appropriate way (which distinguishes it from the TEI Guidelines, whose 
first chapter is quite demanding and makes more sense to someone who has 
already been working with TEI for a while).

It seems to me that there is a natural division between the 
basic/intermediate sections that virtually every user will need to cover 
(outline chapters 1-8) and advanced topics (9-Schemas; and Elena's 
suggested chapter on textual analysis, if we agree to add it). 
Another way to look at it is that chapters 1-6 are applicable to anyone
working with TEI files, including assistants who are simply adding
or correcting content following project guidelines; chapters 7 and
beyond are more applicable to people in charge of projects (including
independent work) or designing TEI-based publications. (This could be
explained to readers in the introductory material.)

I'll volunteer to help with authoring and editing.  Would it make sense
to put the outline document on the TEI Wiki, to make it easier for
people to edit it and keep up to date with changes? (We could use a
"private" Wiki page, not linked from elsewhere, so that the document and
our comments wouldn't be open to the public while work is in progress.)

A few specific comments on the different sections:
======

"About the getting started document"

Audience

As someone (Dan I believe) said during our last telco, we 
should also include in our target audience people who are not themselves 
specialist scholars but who are, or will be, working as encoders with a 
project. These may be undergraduates, editorial assistants, etc. We can 
assume that they are equally motivated with the academic readers, but 
they may not be familiar with the technical vocabulary of textual 
studies, bibliography, etc.

Software

It will take some discussion and maybe experimentation to decide just
how to present the examples connected with different software
platforms. One option would be to illustrate each major task with screen
shots and instructions for each of the platforms we decide to include.
Or we could choose a single platform, say oXygen, for the main
presentation, and link to illustrations of how tasks are handled in the
other platforms via appendices. (Or we could be very clever and compose
alternate texts for the software sections that would be toggled via
reader choice in the online version?)

Contents

"We explain RELAX using the XML syntax, and mention the existence of the
compact syntax." This should be discussed further. In my experience the
syntax of DTDs or Relax NG compact is easier to grasp, and better to
use for the very first example of how schema rules constrain a document.
In chapter 3, we could offer an example of an extremely simple non-TEI
XML language with maybe three elements and one attribute, and show the
Relax NG compact schema used to validate it. Later, in chapter 9, we
could explain the relation between the XML and compact forms of Relax NG
and use the XML form in relation to the ODD discussion.

This is more or less the way that things work elswhere in the TEI world:
the "Gentle Introduction to XML" uses compact syntax, and the Element
reference in the Guidelines defaults to compact; but in the Guidelines
chapters on ODD, the RELAX NG XML syntax is necessarily used.


-- 
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 801079, Charlottesville, VA 22904-4318 USA
Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903
Email: dsewell at virginia.edu   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/