TEI Guidelines, p. 394 - external apparatus

[TEITechnicalCouncil]

"Both the location-referenced and the double end-point methods may be used with either in-line or external apparatus, the former dispersed within the base text, the latter held in some separate location, within or outside the document with the base text."

I assume that the external document mentioned is a TEI document, but in order to accommodate an external apparatus, whether outside or inside the document, something like a <listApp> element seems to be required.

Which location is recommended inside the document?

Original comment by: @jensopetersen

[TEITechnicalCouncil]

This issue was originally assigned to SF user: martindholmes Current user is: martindholmes

[TEITechnicalCouncil]

The point here is a good one. <app> can, naturally, appear virtually anywhere (as it has to in order to perform its function), but there is no natural or recommended way of storing an external collection of <app> elements. It could be stored in a <list> / <item> structure, but that seems excessive. I think the idea of <listApp> has reasonable.

The question then would be where <listApp> could appear. Should it be in the header of the external file, or in the body? If in the header, should it have a specific recommended location? Or should it just be available as a child of, say, <div>, so it can appear either in the header or the text, wherever the encoder prefers?

Original comment by: @martindholmes

[TEITechnicalCouncil]

<del>has reasonable</del> <subst>is reasonable</subst>

Original comment by: @martindholmes

[TEITechnicalCouncil]

There is no current recommendation on this subject. I suspect that most people who take this approach (if such there be) will simply put the <app> elements in a <div type="apparatus"> or some such; I see no need to invent a <listApp> for the purpose. But we should certainly provide some examples and guidance within this chapter.

Original comment by: @lb42

[TEITechnicalCouncil]

• milestone: --> AMBER

Original comment by: @lb42

[TEITechnicalCouncil]

I agree with Lou. And, in fact, when I've done this I did exactly as he suspected: a <div> with a series of standalone <app> elements one after another in it. This seems a straightforward and simple approach to me, I don't see the need for an extra element.

Original comment by: @jamescummings

[TEITechnicalCouncil]

I agree (now) - no new element is needed. I extrapolated from the existence of <listBibl>, which is not needed either.

Original comment by: @jensopetersen

[TEITechnicalCouncil]

• status: open --> closed

Original comment by: @jensopetersen

[TEITechnicalCouncil]

@James: if you did this with <div> containing a series of <app> elements, you must have customized your schema, surely? <app> cannot appear in <div> in the current release, nor in the latest build:

http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-app.html

This causes me to re-think a little. I now think a <listApp> element might be a good idea, but I'm not sure yet how it should fit into the existing infrastructure...

Original comment by: @martindholmes

[TEITechnicalCouncil]

If <listApp> were a member of model.listLike, it would be available in core textstructure elements such as <div>. It should also presumably, like e.g. <listBibl>, be a member of:

att.global (@xml:id, @n, @xml:lang, @rend, @rendition, @xml:base, @xml:space) (att.global.linking (@corresp, @synch, @sameAs, @copyOf, @next, @prev, @exclude, @select))

(att.global.analytic (@ana)) (att.global.facs (@facs)) (att.global.change (@change))

att.sortable (@sortKey)

att.declarable (@default)

att.typed (@type, @subtype)

I can see good use cases for typing and subtyping lists of <app>s, as well as the usual linking etc. att.declarable also makes sense, I think, although I'm finding it a bit difficult to come up with a realistic example usage for this.

Original comment by: @martindholmes

[TEITechnicalCouncil]

Apologies, I left out that I had wrapped these in an <ab> per grouping. (e.g. in case of poetry an <ab> for each large <lg> or poem, in the case of prose for each <div> or <p> depending on the number of variants and the granularity of the <app>.

Original comment by: @jamescummings

[TEITechnicalCouncil]

The Ann Arbor meeting document tasks me with dealing with this. I don't know why the ticket was closed, so I'm reopening it and assigning it to myself.

I've created a basic <elementSpec> for <listApp> (listApp.xml) and added it to SVN in rev 10658. It's lacking examples, and since I don't have any myself, I've written to James and Gabby to see if they do. There will also need to be substantial revision to the TC chapter, starting with #TCAPEN.

Original comment by: @martindholmes

[TEITechnicalCouncil]

• assigned_to: nobody --> martindholmes
• status: closed --> open

Original comment by: @martindholmes

[TEITechnicalCouncil]

As of rev 10719, the listApp spec has a decent example in it, and I've integrated it into the Guidelines and added a brief discussion of it in the TC chapter (12.2). I'm going to leave the ticket open for a little while longer in case anyone comes up with a second example (the one I have is a bit complicated), or Council feels that the explanation of <listApp> in TC is not substantial enough. If no-one complains, though, the ticket could be closed in a month or so.

Original comment by: @martindholmes

[TEITechnicalCouncil]

• status: open --> open-fixed

Original comment by: @martindholmes

[TEITechnicalCouncil]

A month or so has passed, so I am closing the ticket!

Original comment by: @lb42

[TEITechnicalCouncil]

• status: open-fixed --> closed-fixed

Original comment by: @lb42