[tei-council] Revised AB

[Lou Burnard]

Syd Bauman wrote:

> 
> 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 ...".

You are quite right. I've changed it accordingly.

> 
> 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". 

I don't think I've seen that view expressed by anyone yet. Christian 
expressed surprise that WD was (at that stage) presented as the first 
chapter, which it is no longer. I think it is a generic chapter.


>> 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 am standing by for any indication that anyone agrees with you on this 
(rather trivial in my view) issue.

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

And we also make life a whole lot easier for people wanting to use the 
TEI for *reliable* interchange.  Nuff politics.


> 
> 
>>> * #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"?

yes, that was a typo, now fixed. tx.

> 
> "... very rarely require that you make use of any particular feature
> they propose, but they do ..."
> 
no, the "features" are in the texts not the Guidelines.
> 
>> Why? that's what "their" means!
> 
> Because this is formal prose.

Yes. And?

> 
> 
>>> @ #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.
> 

Now reads "Because no
predefined encoding scheme can possibly serve all research purposes,
the TEI scheme is designed to facilitate both selection from a wide
range of pre-defined markup choices, and the addition of new (non-TEI)
markup options."