[tei-council] tcw20.xml (Editing the TEI Guidelines)

[Martin Holmes]

Hi Kevin,

On 12-09-13 10:48 AM, Kevin Hawkins wrote:
> On 9/13/2012 12:00 AM, Martin Holmes wrote:
>> Hi Kevin,
>>
>> On 12-09-12 07:43 PM, Kevin Hawkins wrote:
>>> While this is very helpful, it seems that the first half of it needs to
>>> be adapted for inclusion in chapter 23 of the Guidelines. That is, we
>>> would not refer to specific files like att.datable.xml and not refer to
>>> something that has already been added into the Guidelines. After all,
>>> if anyone not on Council wants to use Schematron, they would never think
>>> to look at tcw20 (or even know it exists)! What you would leave here is
>>> the explanation of how trunk/P5/Text works and what follows.
>>
>> I have nothing against including it in the Guidelines, but I think if we
>> do start explaining how to use Schematron in the Glines we'll have to
>> start from the assumption that readers know less and are much less
>> familiar that Council members are with the TEI infrastructure. That
>> wasn't my brief. I'm trying to write specifically for people with enough
>> understanding of the system that they've made some edits in trunk
>> already, seen Jenkins build, and are ready to move on to something
>> slightly more challenging.
>
> Right, I understand.  But the first half of
> http://hcmc.uvic.ca/people/martin/tcw20.html#schematron does not assume
> that a user knows anything about the TEI infrastructure beyond what's
> already in the Guidelines.  So I think it could be incorporated easily
> enough.

We should decide whether it's the business of the Guidelines to cover 
slightly peripheral and advanced topics such as Schematron. If so, it 
would be easy to write a full section which assumes no knowledge on the 
part of the reader. The TCW20 section could then refer to that part of 
the Guidelines. But I'm not sure we really want to deal with Schematron 
in the Guidelines in any more detail than is already here:

<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS>

>>> b) I don't care for use of "to fire" and "to be fired" in reference to a
>>> test condition.
>>
>> I think it's pretty much exactly what happens. We could use "triggered"
>> too. What else do you suggest?
>
> While "triggered" is okay, I prefer something more neutral like saying
> that a condition is met or satisfied.  "To fire" wouldn't easily
> understood by a non-native speaker.

I went for "triggered", because it seems to me a better way to capture 
the notion that when a condition is met, something happens (or in the 
case of <report>, when a condition is not met, something happens).

Cheers,
Martin

> --K.
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)