[tei-council] [Fwd: Library SIG recommendations]

[Dan O'Donnell]

Hi all,

The following is Perry's suggestions for incorporating Library SIG 
corrections into TEI Tite. This was something we decided to ask Perry to 
do while we were meeting in the cafe basement.

I'm not 100% sure how best to get these discussed and they fell a little 
between the cracks between Laurent and me last week during the Easter 
week. But we need to discuss and make any final changes necessary to the 
version we want to provide to the vendors within the next week and a half.

Any suggests for how to handle them? A red-light, yellow-light, 
green-light system? A "look em over and object" system?

-dan

-------- Original Message --------
Subject: 	Library SIG recommendations
Date: 	Sat, 11 Apr 2009 01:11:20 -0500
From: 	Perry Trolard <perry.trolard at gmail.com>
To: 	daniel.odonnell at uleth.ca
CC: 	ptrolard at artsci.wustl.edu



Hi Dan,

Just in time, I hope: the write-up for council. Let me know if I can
add anything, provide more background, etc.

Best,
Perry

-----

The TEI-in-Libraries SIG's recommendations are here

	http://wiki.tei-c.org/index.php/Review_of_Tite_Scheme

and supplementary information & an extensive read-through by Kevin
Hawkins are at

	http://www.ultraslavonic.info/tei_tite_revisions/

(the images are of Hawkins' hand-written notes).

Humongous thanks to members of the SIG for taking the time to read the
Tite docs so carefully (especially Kevin Hawkins).

Most of the material from the above concerned edits to the prose
documentation (to correct mistakes; promote clarity, consistency of
usage, & appropriate tone; fix typos, etc). I've incorporated much of
this into my version of the ODD file, which is attached in full & as a
diff (against SVN r5763) for those who are interested in these
changes.

The more substantive changes that I suspect will interest Council
follow (with my recommendations).

 * Documentation on "soft" vs. "hard" hyphens: it was pointed out that
though the Tite docs required that vendors maintain the difference
between these in transcriptions, it didn't specify *how* to do so. The
suggestion was to use the SOFT HYPHEN character (U+00AD) to transcribe
soft hyphens, and the Western-keyboard default hyphen, the
HYPHEN-MINUS (U+002D), for hard hyphens. (This entails no change to
the schemaSpec.)

	-- I think the recommendation is a good one. It allows for the easy
identification of soft hyphens, so subsequently projects can either
(1) remove them if uninterested in them or (2) add markup to them
(say, regularize them inside a choice/(orig|reg) pair). Using markup
to identify soft hyphens (say, with lb elements) would add keystrokes
& may also make it less easy to identify them.

 * Necessity of the teiHeader: it was requested that the teiHeader be
removed from the Tite documentation, as vendors will not be expected
to create or maintain headers. Headerless documents (with text as
their starting element) will validate against the Tite schema, but, as
I understand it, won't be TEI-conformant. (This would not *require* a
change to the schemaSpec, which already specifies both TEI and text as
valid root elements).

	-- I defer to the Council on questions of conformance, but my two
cents is that since Tite documents should have a short life after
being delivered from the vendor (before they're converted, say, to TEI
Lite), this kind of macro-level conformance is less important; Tite
conforms to the TEI abstract model in the details of the markup of the
transcription.

* Inclusion of the g element: it was suggested that the g element
would be necessary if Tite is to be used with texts in Asian character
sets ("Far East projects" -- I assume this is equivalent )

	-- I may not understand all the issues motivating the suggestion, but
my impression is that it's too much to ask vendors to identify (&
name?) non-standard glyphs or characters, as would be required to need
the g element; none of the library vendor specs that are the basis of
Tite included instructions on identifying non-standard glyphs. How
should a vendor handle glyphs they don't recognize, then? Based on the
library vendor specs: gap elements.

Finally, there were some suggestions about the presentation of the ODD
documentation on the TEI website. Elements that seem to be in need of
special rendering are:
	* term
	* att
	* docTitle/titlePart (currently, where there is more than one
titlePart, the contents of each seem to be combined, w/o spaces)



-- 
Daniel Paul O'Donnell
Associate Professor of English
University of Lethbridge

Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
Founding Director, Digital Medievalist Project (http://www.digitalmedievalist.org/)
Chair, Electronic Editions Advisory Board, Medieval Academy of America

Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidental)
Home Page: http://people.uleth.ca/~daniel.odonnell/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tei_tite.odd
Type: application/octet-stream
Size: 51752 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20090423/1ff9ea47/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tei_tite.odd.pjt-10Apr2009.diff
Type: application/octet-stream
Size: 30884 bytes
Desc: not available
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20090423/1ff9ea47/attachment-0001.obj