[tei-council] Revised AB

[Syd Bauman]

> If you are going to do anything with characters you need WD. You
> can get through a whole lifetime of encoding without needing to
> touch either NH or CE, fortunately.

Well, yes, but very few projects need to do anything with characters.


> You are assuming one topic per chapter. There are two chapters on
> character related issues, and three on manuscript related issues.

Current arrangement (last column from #ABSTRUNC/p[2], "The first four
chapters ... likely to be of importance to any one ... The next eight
focus on particular kinds of text: ... The next nine chapters deal
with ... specialist applications ... The last two chapters deal with
the XML encoding used to represent the TEI scheme itself, and provide
technical information ..."):

01   ST   The TEI Infrastructure             general
02   HD   The TEI Header                     general
03   CO   Elements Available in All TEI...   general
04   DS   Default Text Structure             general
05   WD   Representation of Non-standar...   genre   # see below
06   VE   Verse                              genre
07   DR   Performance Texts                  genre
08   TS   Transcriptions of Speech           genre
09   DI   Dictionaries                       genre
10   MS   Manuscript Description             genre
11   PH   Representation of Primary Sou...   genre
12   TC   Critical Apparatus                 genre
13   ND   Names, Dates, People, and Pla...   special
14   FT   Tables, Formulae, and Graphics     special
15   CC   Language Corpora                   special
16   SA   Linking, Segmentation, and Al...   special
17   AI   Simple Analytic Mechanisms         special
18   FS   Feature Structures                 special
19   GD   Graphs, Networks, and Trees        special
20   NH   Non-hierarchical Structures        special
21   CE   Certainty and Responsibility       special
22   TD   Documentation Elements             technical
23   USE  Using the TEI                      technical

Chapter WD seems to be mis-categorized on two axes, here. First, even
if we are to grant your idea that WD is a topic that is "likely to be
of importance to any one intending to apply the TEI scheme", it is
not about a genre. It is a general topic, so those sentences should
read "The first five chapters ..." and "The next seven focus on ...".

However, Christian and I, and perhaps others, are of the opinion that
WD is not a general-purpose chapter, but instead a chapter more in
line with "specialist applications". In which case the arrangement
should be

01   ST   The TEI Infrastructure             general
02   HD   The TEI Header                     general
03   CO   Elements Available in All TEI...   general
04   US   Default Text Structure             general
05   VE   Verse                              genre
06   DR   Performance Texts                  genre
07   TS   Transcriptions of Speech           genre
08   DI   Dictionaries                       genre
09   MS   Manuscript Description             genre
10   PH   Representation of Primary Sou...   genre
11   TC   Critical Apparatus                 genre
12   ND   Names, Dates, People, and Pla...   special
13   FT   Tables, Formulae, and Graphics     special
14   CC   Language Corpora                   special
15   SA   Linking, Segmentation, and Al...   special
16   AI   Simple Analytic Mechanisms         special
17   FS   Feature Structures                 special
18   WD   Representation of Non-standar...   special
19   GD   Graphs, Networks, and Trees        special
20   NH   Non-hierarchical Structures        special
21   CE   Certainty and Responsibility       special
22   TD   Documentation Elements             technical
23   USE  Using the TEI                      technical

Although I could see re-arrnaging the special chapters a bit.
Perhaps: 

12   ND   Names, Dates, People, and Pla...   special
13   FT   Tables, Formulae, and Graphics     special
14   SA   Linking, Segmentation, and Al...   special
15   CC   Language Corpora                   special
16   AI   Simple Analytic Mechanisms         special
17   WD   Representation of Non-standar...   special
18   FS   Feature Structures                 special
19   GD   Graphs, Networks, and Trees        special
20   CE   Certainty and Responsibility       special
21   NH   Non-hierarchical Structures        special

(I put NH last because it doesn't define a module, which may not be a
good reason.)

(Doesn't this look like it is crying out for us to put the <div
type="part">s back?)


> Ah yes, we should certainly mention that convention [slashes in
> representation of names of empty elements] if we retain it. I think
> on balance the council disagreed with you, so I have now added a
> sentence explaining it (it can always be removed if people come
> round to your way of thinking)

Council did not actually vote on the topic, but the general mood in
the room was that Council disagreed with me with respect to slashes
in empty element names in <specDesc> output, and that they should
stay at least until everyone got to look at them (they were pretty
new then). Council didn't even have the chance to have a mood about,
let alone discuss or vote on, slashes in empty element names in <gi>
output, because when I raised the issue of the slashes, James said
that they were not going into the <gi> output.

I really don't like 'em. It's sorta like adding a small icon after
the name of any person who's short.


> I think this is nonsense. We dont curtail flexibility or
> extensibility by requiring that people be explicit when they flex
> or extend.

No, and I concede that "curtail" may be too strong a word. But we
erect barriers to flexing and extending by requiring namespace
purity for conformance. 


> agreed: have replaced "which.... language" by a bib ref to the W3
> Rec for XML (if you don't know what XML is, reading this para wont
> help you)

Good point!


> > * #ABTEI2/p[3], last sentence ...
> Certainly not a sentence I'm proud of. Try this one:

Defintely better. The three uses of "require" seem a bit much,
though. And I'm not clear if the second one means "require any
particular feature of the text be encoded" or "require any particular
feature of the Guidelines be used".

How about changing the second one to "use", "always use", "encode"?

"... very rarely require that you make use of any particular feature
they propose, but they do ..."


> Why? that's what "their" means!

Because this is formal prose.


> > @ #ABTEI2/p[9], 2nd sentence ("Because no predefined ..."): I am
> >   uncomfortable with the implication that the term "customization"
> >   only refers to reducing the scope -- we have always (including in
> >   MD, I believe) used it to mean both reductions and modifications by
> >   adding new stuff.
> >   
> 
> Not sure what you're proposing here. We do want to say there are
> two kinds of thing going on -- cutting down from tei_all and adding
> new stuff. I'm proposing words for those two distinct operations:
> what words would you prefer?

     ... the TEI scheme is designed to facilitate customization both
     by reducing what markup is permitted in a given set of documents
     and by the addition of new non-TEI markup.


> "Special-purpose software may be used to transform word-processed
> or scanned text automatically. "

Sounds fine. 


> Well if it makes you happy, I don't mind pretending that a single
> value "n" can be considered as a formula.

It's a very boring formula :-)