Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Fabio Ciotti rightly points out on the Council list that the example using @corresp here:
should actually be using @synch. The example dates back to the P4 Guidelines.
Assigning to Fabio Ciotti to triage, propose a change, and implement.
I'm going to rewrite the example and the relevant lines of text
My intuition tells me this is not necessarily a good correction. A play is not like a transcription of a spoken interaction where things can be matched onto a temporal axis. It is an abstraction, as series of instructions provided by a a didascalos. In the example mentioned here. The stage direction corresponds to the series of line, which in turn could be uttered by the actors in more or less any kind of order. I would have nothing against keeping @corresp...
Laurent, your observation is interesting ad thoughtful. But in this case you have two distinct phenomena:
"in the original, the stage direction ‘in consternation’ is printed opposite a brace grouping all four speeches, indicating that all four characters speak at once".
1) so the four speeches are synchronous
2) the stage direction is referred to all of them
In my opinion 1) is a perfect candidate for the intended meaning of @synch attribute and 2) is a bad candidate for the intended meaning of @corresp. In fact the didascalos properly doesn't have a correspondence with each of the speeches, but it is referred to the four at the same time. In my view correspondence imply a sort of invariance by substitution, and this is not the case. Actually here I'd use a typed <link> element.
Any other thought on this?
This obviously makes me think we should have an <spGrp> element to group such ... groupings. Whether @synch or @corresp (but you know my feelings already), this would point to the encompassing <spGrp> element. A very small leap, I think.
If I may add a historical perspective... this example actually goes right back to P2, The source contains an interesting comment:
"In the example, the <gi>stage</gi> element has been moved
to an arbitrary place, and the four speeches with which it is to be
associated are specified by identifier as the value of the
<att>corresp</att> attribute. This attribute, which is enabled by the
linking tag set, provides the simplest way of indicating the temporal
alignment of speeches or actions in a play.
<!-- I need help deciding how (or whether) to represent this -->
<! -- with the ALIGN element -->
<p>More powerful and more precise mechanisms for temporal alignment are
defined in chapter <xref target=TS>. These would be appropriate for
encodings the focus of which is on the actual performance of a text
rather than its structure or formal properties.
The ALIGN element mentioned here is a precursor of the <when> element, in the process of definition at the time this draft was published. I conclude that if the drafter of this section had received the help requested, they would indeed have used @synch rather than @corresp. The intention is clearly to represent temporal alignment according to the mechanisms defined in the chapter on transcribed speech.
Interesting. I still do think that there are two different scenarios here:
- a a-temporal one with the drama and its sequence of abstract instructions
- a temporal one when the play is being performed
In the latter case I would of course use the speech transcription modules and all temporal objects to record the precise occurrences of what the actors say and do. For the former, @corresp conveys well the abstraction.
I also see part of my previous comment has been erased (angle brackets, grrr)... I suggested the introduction of a spGrp element.
The sequence of abstract instructions is not a-temporal though: the printed brace and associated stage direction in the source are there to indicate something about the order in which the speeches are given, Whether using @sync to encode this necessarily implies that the whole encoding is representing a performance of the text I rather doubt. Clearly it shouldn't -- that's why we use <sp> rather than <u> for example. HOWEVER, it's not hard to think of other examples where speeches are braced together with a stage direction with no implication of simultaneity, In which case, I come round to thinking that the suggestion of using <spGrp> makes a lot more sense than either of these pesky attributes.
In the end I've come to think that, given the actual tagset, the best way to describe this example is using @sync attribute on the first <sp> to assert the fact the the four speeches are simultaneous, and keeping @corresp in the <stage> to express the fact that it is a meta instruction that refers to all of them. The idea of a more general <spGrp> to model this and other similar situation is fine, though. But if it is a container it could easily catch OH cases. It should work as an off-line markup, like <linkGrp> and similar.
Council agreed that example should use the "spGrp" element (with type="simultaneous" or some such); nearby prose needs to be changed accordingly, and should say that if user wants more detailed temporal alignment to see TS or whatever.
Fabio will write up his suggestion and send to TEI Council list.