TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
279 stars 88 forks source link

rs should contain q and quote #1531

Closed ebeshero closed 6 years ago

ebeshero commented 7 years ago

As raised on the TEI list on Oct. 30, 2016, we can't nest a <q> (or a <quote> element inside a <rs> element . The examples from Scott Vanderbilt's archaeology project posted on the list look like unusual but plausible use-cases fpr <rs> to contain quoted material, and might be useful in the Guidelines to broaden diversity of examples in the Guidelines, should we decide this ticket is "Go." This example looks especially useful:

   <rs type="findspot">in excavation, re-used in a fourth-century
   <q>chalet</q></rs>

and perhaps this:

<rs>The town <quote>formerly known as Princeton</quote></rs>
jamescummings commented 6 years ago

Again, just to be clear, length has nothing to do with it. (No jokes intended.)

A lot of what people have used here as examples for rs I don't think are really (in the whole phrase) standing in or referring to a name. Yes, for lots of them I might use seg, with an rs inside. Though to be honest I've rarely used rs.

As for serious research questions... IMHO these are helped by consistency and a tighter TEI Guidelines rather than a tendency towards entropy and loosening of them when alternative applicable structures already exist. I think part of our job is to resist calls for change unless they meet a good burden of necessity. Again, I'm not adverse to rs (etc.) having q inside it.

But I've probably expressed my opinion too much on this issue. A F2F group already approved it, did they not?

ebeshero commented 6 years ago

@jamescummings Yes, and we all did discuss it together or we wouldn't have green-lighted it. That said, I agree with you (from my own experience with new TEI coders) that people really want to apply <rs> in any way that "refers" and not quite understanding the precision naming function that we are giving it. That is, this is an element people tend to want to stretch to their own purposes because "referencing string" sounds very friendly and applicable. I think the problem might be bigger than this ticket, and probably worth its own ticket: Do we need more and better examples of when <rs> is well and fitly applied, and when it is not?

sydb commented 6 years ago

While I have not read every snippet of today’s detailed conversation, I can say reasonably confidently that (IMHO):

  1. @jamescummings is correct, the original post is an abuse of <rs>
  2. @ebeshero is correct, there are cases where <q> inside <rs> (or <name>, I suppose) is quite reasonable. I think the buck stops here example is a good one.

But @lb42 has really hit the nail on the head — due to the way TEI classes are set up, this may (or may not) turn out to be quite hard to do. E.g., adding model.qLike to macro.phraseSeq is likely to result in ambiguous content models, no? I’m going to play a little and get back to you with a preliminary on that. (Although I should add that I am not in favor of self-immolation over TEI elements. That’s why TEI is a modifiable system, so users can modify TEI for their own use instead of performing dramatic acts of suicide.)

sydb commented 6 years ago

Hmnmm… I just tried it. I created a copy of the current 'dev' branch that had no changes except that I added model.qLike to macro.phraseSeq. I did not notice any new icky errors go buy during the build. I then built a tiny little XML file that had a <q> inside an <rs> and used the tei_all.dtd. I expected to get ambiguous content model errors, but neither oXygen nor xmllint complained at all.

So I have just checked it in at 206c146, and we’ll see if Mr. Jenkins or anyone else finds something to complain about. (In which case it is quite easy to back out even w/o the use of git version control: just delete “<classRef key="model.qLike"/>” (currently line 28) from Source/Specs/macro.phraseSeq.xml.)

lb42 commented 6 years ago

You won't be surprised to hear that I share James's reservations about this change.The OP's use case is invalid, and the only arguments advanced in favour of making the change seem purely suppositious and theoretical. A subgroup of council can change its mind, surely?

sydb commented 6 years ago

Per Council meeting, ticket closed. Those interested may open a new ticket for providing better examples in GLs.