Processing xml:ids for stage directions in modern texts

[mahaylagalliford]

We want to add to the processing for the ASSP system to include stage directions: ASSD. Act and scene will be processed as usual, while the SD pulls from the xml:id on stage elements. We do not want speech included in canonical references for stage directions (see rationale). For example, xml:ids see emd1HW_M (act 1, scene 1 and act 3, scene 1). We have a <ptr> from emd1HW_M_annotation linked to SD with xml:id="emd1HW_M_a3_s1_sd21". For this example, we want its render as: A3 Sc1 SD21

Rationale: From my JCURA research I learned that stage directions are paratextual material and that we need to be able to link to them in modern texts. LEMDO has not yet resolved the question of how to make stage directions citable and linkable in the modern texts. I recommend a citation system similar to our ASSP system, however, since stage directions are paratextual, they are contained to the scene and are independent from the surrounding text. Therefore, I suggest that, within each scene, we give every stage direction an xml:id numbered sequentially (sd1) and that we start the numbering process over again with each new scene.

[martindholmes]

What if you have a pointers which spans from a stage-direction to a subsequent speech?

[martindholmes]

Expanding on this a bit, I see two problems, or at least issues that we'll need to clarify before we can proceed:

1. Unless stage direction numbers/ids appear in the margin, the reader won't be able to navigate with them, in the PDF and in the online view. But because they can co-occur with the beginnings of speeches, it won't always be possible to put their identifiers in the margins in the PDF. In the H5 pdf, p.20 (A2 Sc1 Sp20) you'll see one of many examples of this. In the online version, because we always have a linebreak following the speaker name, this is not so much of a problem, but it's a killer for the PDF. We'll have the same problem for any stage direction that co-occurs with a line number. I can't see a solution to this, other than to prioritize one and discard the other, which will be mighty confusing for readers.
2. It's not clear what should happen if an editor annotates a span which begins or ends inside a stage direction but spans outside it. Should we just assume that because non-SD content is involved, we should ignore the SD component in the reference?

[LEMDO-PM]

1. I think that we discussed not adding SD numbers in the PDF for that reason. I'll ping @JanelleJenstad to confirm that. Could we leave the processing as-is for the PDF and add processing for @xml:id on <stage> in our digital output?
2. Yes, I think that that's fair. If we didn't add SD numbers in PDFs, does this question still stand for annotations? For parenthetical citations, could people simply add two <ptr> elements with an en-dash between so that it would render as, for example, A3 Sc1 SD21-A3 Sc1 Sp30?

[martindholmes]

@LEMDO-PM

Re 1, yes, we can ignore these things in the PDF, but that will mean that editors will have to avoid using them entirely in any text which may form part of a PDF at some stage. That doesn't seem easily enforceable.

Re 2, I agree that two ptrs is the way to do this sort of thing, but editors are not necessarily going to know or notice when they cross these boundaries. They're used to using a single pointer to two anchors to annotate a span (there are currently 2273 localCit pointers which point to a pair of anchors). We could have a Schematron rule which says that you can't have a single anchor inside a stage-direction -- in other words, you either point directly to the stage direction's id or you point to two anchors inside it. But there are already 62 cases of a single anchor inside a stage direction, so there would be significant remediation to be done.

[martindholmes]

@LEMDO-PM I see you removed the blueSky label, but we still don't have any practical plan for handling this. The two major problems remain:

1. Stage directions coincide with every other ASSP marker type, which means there will be collisions all over the place and no practical way to show their ids/anchors in the HTML.
2. For that reason we can't display them at all in the PDF, where page width is already a problem, and therefore any link pointing to a stage direction will be confusing for readers in the PDF.

I think this is entirely impractical, UNLESS we force all stage directions to be block elements starting on a new line. If we can do that, then this is feasible. How do we feel about that?

[JanelleJenstad]

I have a different suggestion:

• DON'T display SD numbers in the HTML or PDF at all. It's too messy. However, rendering problems should not stop us from doing something valuable in the XML. So we should:

• GIVE elements an xml:id. They can be consecutive in the semi-dip texts from _sd1 to _sd??. In modern texts, they can be constructed as I've suggested before: emdABBR_M_a1_s1_sd1 (with no reference to speeches).

Giving them xml:ids allows us to do the following:

• Link to stage directions
• Display stage directions in a separate file (as the Oxford, New Oxford, and Oxford Middleton do), where the numbers can be displayed.
• Make it possible for other interfaces to be built in the future (for example, an interface in which all stage directions are put in an adjacent column, as some print editions have done recently)

Bottom line: The difficulty of processing into a clickable number should not stop us from assigning xml:ids.

[martindholmes]

@janelleJenstad There are already 266 stage directions with @xml:id, and these turn into @ids on the HTML output element, so they can be linked to. There are two actual pointers linking to these, one in emd1HW_M_annotation.xml and one in emdJC_TextIntro.xml. The links actually work in the output, but in the first case the link text suggests there is an error, and in the second, only the word "link" appears.

So the next question is what link text should show up for these types of links. The suggestion above for expanding the id into act, scene, stage-direction works for me; although that doesn't represent a caption or label that appears in the text, it would at least make some sense to the reader. What do you think?