Modern texts need a separate character listing page

[martindholmes]

The requirement is:

1. Every modern text should be accompanied by a file named [modern-text-id]_characters.xml. This is essentially a critical paratext that may include any amount of prose, but will also, somewhere, include a processing instruction that will trigger the import of a well-rendered version of the characters listPerson from the modern text.
2. When the character list is rendered into that file at (say) originalXml build time, the ids of the characters will be morphed to match the host file id, and those ids will become HTML ids in the output.
3. A new prefixDef role: will be created, which can be used to point from anywhere in an edition to the xml:id of a character in a modern text character list. Diagnostics will check that such links point accurately, and only within an edition.
4. That prefixDef link will be converted at originalXml time into a pointer to the file + id of the character in the _characters.xml file.
5. At standalone time, those links will be used to trigger import of all characters pointed at from a page in the edition into that page, where they will be part of the appendix and function as popups in the normal way in the HTML output.

[martindholmes]

@JanelleJenstad @LEMDO-PM We already have 15 files with the name/id format "..._Characters.xml" (not lower-case c, as specified on the ticket). None of these have any processing-instruction yet. So am I right to assume:

1. The original specification above is wrong, and the key filename has an upper-case C?
2. These are the files which are going to include this processing instruction?
3. The _Characters file must have the same publication status as the source modern edition that it's going to be populated from?
4. There needs to be some way for the processing instruction to point to a specific modern edition, in the case where there may be more than one?
5. Any file which includes a role: link, and has a published status, should trigger an error if the two sources (the modern edition and the _Characters file) do not also match that status?

This does seem to me to be a bit tortuous, especially when we already have an HTML rendering of each character in the modern edition itself. Would it not be better just to allow links like this:

<ref target="role:emdH5_FM#emdH5_FM_KingHenry>Henry V</ref>

and have that link trigger the import of that character's info into the appendix of the document containing the link, so it would become a popup in the normal way?

[martindholmes]

@LEMDO-PM @JanelleJenstad Is this one dying a peaceful natural death?

[JanelleJenstad]

The PI might be moribund but the ticket is not.

@JanelleJenstad @LEMDO-PM We already have 15 files with the name/id format "..._Characters.xml" (not lower-case c, as specified on the ticket). None of these have any processing-instruction yet. So am I right to assume:

1. The original specification above is wrong, and the key filename has an upper-case C?

Any files with an uppercase C are unremediated IML files. I will do an svn rename of those files.

2. These are the files which are going to include this processing instruction?

Yes.

3. The _Characters file must have the same publication status as the source modern edition that it's going to be populated from?

Yes.

4. There needs to be some way for the processing instruction to point to a specific modern edition, in the case where there may be more than one?

Yes. For example, H5 includes a modern Q and a modern F text, each with its own character list. So we will need two files for the two character lists, each pulling in the <listPerson> from a particular modern text.

5. Any file which includes a role: link, and has a published status, should trigger an error if the two sources (the modern edition and the _Characters file) do not also match that status? I'm not sure what you are asking here. Will pop into the lab to clarify.

This does seem to me to be a bit tortuous, especially when we already have an HTML rendering of each character in the modern edition itself. Would it not be better just to allow links like this:

<ref target="role:emdH5_FM#emdH5_FM_KingHenry>Henry V</ref>

and have that link trigger the import of that character's info into the appendix of the document containing the link, so it would become a popup in the normal way?

Not better (although that would be a cool feature!) because the point of this ticket is to have a page that users can bookmark, keep open, and link to when they use the edition. Also (as with collations and annotations), a lot of work goes into character lists, and we'd like to be able to display it in the edition.

[martindholmes]

@JanelleJenstad What's the timeline for this, and which anthologies need it to be implemented before they can be published? How much additional build time are you willing to add to make this happen? Is it more or less important than getting the annotation/collation processing rewritten?

[JanelleJenstad]

@martindholmes If we have to choose, let's prioritize annotation and collation processing. QME is supposed to release at the end of September and should have character lists. But we can release without the character lists for QME.

DRE is supposed to release at the end of November (fingers crossed) and it will definitely need character lists.

[martindholmes]

Sounds good. I have a proof of concept for the annotation/collation work and I'm hoping to put a couple of days into it during pro-d. It's an approach that will work for other things.

[martindholmes]

@JanelleJenstad The collation/annotation work has become too complicated to undertake in the short term when releases are expected; we're now talking about changing the output page rendering too. So I think we could put this one back on the table as something to be achieved by DRE release time. We need a window of very low activity to do the collation/annotation stuff, because the build will be broken for several days.

[martindholmes]

@JanelleJenstad We still have the following files with upper-case C:

./JC/crit/emdJC_Characters.xml ./Tmp/crit/emdTmp_Characters.xml ./Lr/crit/emdLr_Q1M_Characters.xml ./Lr/crit/emdLr_FM_Characters.xml ./FBFB/crit/emdFBFB_Characters.xml ./Oth/crit/emdOth_Characters.xml ./1H4/crit/emd1H4_Characters.xml ./HW/crit/emdHW_Characters.xml ./FV/crit/emdFV_Characters.xml ./Rom/crit/emdRom_Characters.xml ./Tro/crit/emdTro_Characters.xml ./AYL/crit/emdAYL_Characters.xml ./Leir/crit/emdLeir_Characters.xml ./Cym/crit/emdCym_Characters.xml

Since some of these are part of the QME release that just happened, I think it will be problematic for future releases to change their case now, so I would suggest that we revise the plan to settle on the upper-case C.

[JanelleJenstad]

They can still be renamed. They weren't included in the editions and weren't included in the release. @LEMDO-PM will rename them today. There may be some fall out if there are links in the converted IML files, but we can deal with those rapidly.

[LEMDO-PM]

Done. They should all be lower case _characters now.

[martindholmes]

See comment on issue #209.

[martindholmes]

Since two files whose filenames differ only in case will confuse a lot of people and systems, I suggest we use another format for these files. How about emdH5_FM_roleList.xml?

[martindholmes]

@LEMDO-PM @JanelleJenstad Any comment on the above?

[JanelleJenstad]

Since two files whose filenames differ only in case will confuse a lot of people and systems, I suggest we use another format for these files. How about emdH5_FM_roleList.xml?

_roleList is an excellent filename pattern. Let's go with it.

[martindholmes]

As of rev 20187, original XML pages are being created from candidate cast lists. Right now they're just being copied to the output but in the body of the text; we'll have to see whether anything usable results from that, or whether we'll need to transform them into some other form to get a usable output.

[martindholmes]

As of rev 20190, a valid generated file is being created at least for emdH5_FM.

[martindholmes]

As of rev 20196, the original XML generated is now valid.

[martindholmes]

As of rev 20199, the roleList pages are now being rendered just like the popup character list. What remains to be done is the insertion of a link to the character listing into the edition page.

[martindholmes]

As of rev 20208, the edition file should now contain the appropriate links. Waiting to see if the build succeeds, and if so, this ticket is complete.

[martindholmes]

Works well, looks OK, closing this ticket.