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

[David Sewell]

I have looked fairly quickly at the Wiki review, Kevin's handwritten
editorial changes, and the diff file that Perry sent.

Just two comments:

1. I vote "yes" on including <g>. It is easy to write project-specific
instructions for encoding non-Unicode characters using <g>.

2. In the Wiki review, I'm not clear on the import of "Incorporate
outside documentation (for example, Virginia's DLPS documentation) into
this document so it can stand alone." (see
http://wiki.tei-c.org/index.php/Review_of_Tite_Scheme#general_comments).
Does this mean the Library SIG feels that Perry's documentation of Tite
(i.e.
http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html)
is not sufficient instruction for keyboard vendors? Incorporating the
Virginia DLPS guide
(http://pogo.lib.virginia.edu/dlps/public/text/vendor/vendor.html) would
be a *major* job.

David

On Thu, 23 Apr 2009, Dan O'Donnell wrote:

> 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)
>
>
>
>

-- 
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/