Current SF Tracker Items (18 Aug 2008)

This lists SourceForge tracker items which are currently open, and which have been classified as GREEN, AMBER, or RED by the Oxford Editorial Team.

GREEN items are ones which :-

• seem to be desirable enhancements
• are clearly specified as to what needs doing
• have been agreed to by at least one other Council member

AMBER items are ones which :-

• may be desirable or may not
• need further detail or investigation
• have not been fully evaluated or considered

RED items are ones which :-

• need substantial extra work or consideration
• are not yet sufficiently clearly expressed to be acted upon

We recommend to Council that :-

GREEN items

1848442: Attributes missing

1. The element <name> should have att.typed as one of its classes, to add 'subtype' as an attribute (as i.e. <persName> has). And 'type' should be removed at a local attribute in <name>, as that is included in att.typed.
2. The attribute 'extent' in <gap> should probably be 'quantity' to be consistent with for instance <space>. The correct thing is probably to add the class att.dimensions to <gap>, and remove its local attributes 'unit' and 'extent'.

Comments received

1852100: nameLink element should not have @ref or @key attribute

It seems to me that att.personal should not be a member of att.naming, because this allows nameLink to be used with @key or @ref as an identifier for a person, something which seems highly improbable to me, to say the least.
Because nameLink is a member of att.naming (via att.personal), it can have a @ref or @key to identify the entity being named by the nameLink - yet nameLink is not in fact a name.
"<nameLink> contains a connecting phrase or link used within a name but not regarded as part of it, such as van der or of." http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-nameLink.html
For example, this is valid, but, I submit, nonsensical:
<persName> <forename>Frederick</forename> <nameLink key="frederick.van-der.tronk">van der</nameLink> <surname>Tronck</surname> </persName>
This glitch can be resolved by removing att.personal from att.naming, and instead explicitly including in att.naming every member of model.persNamePart EXCEPT nameLink.
I also wonder whether persName itself needs @sort? http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.personal.html

Comments received

1852101: title element should be a member of att.naming

Clearly a <title> is a name of a thing, and I think to be consistent we should treat it like other kinds of names, where we've allowed encoders to identify precisely which thing is named, by reference to an entry in an authority file or similar (using @key or @ref). Adding <title> to att.naming would allow that.
I guess <lang> is a similar case.
See thread on Council list: http://lists.village.virginia.edu/pipermail/tei-council/2007/009215.html

Comments received

2032853: condition not allowed within binding

The <condition> element for recording the physical state (e.g. extent of any damage etc.) of a manuscript can only be used within <physDesc>, where it relates to the whole object. There is no way of specifying such information solely with respect to the binding. This could be rectified by permitting the <condition> element as a child of <bindingDesc> or <binding>

1927987: Named time periods

Before the release of P5 we had agreed on the addition of an attribute @period that could point to named time periods.
Quoting from Lou's email (April 2007) to the council list (http://lists.village.virginia.edu/pipermail/tei-council/2007/007409.html):
"Named time periods. The treatment of dates and times has just undergone major surgery in order to support various kinds of automatic processing and validation, mappings to both ISO and W3C date formats etc. When the patient is mobile again, I agree that we need to start thinking about "named" dates. It should not be too difficult."
So, at the moment, we do have the attribute @period as member of att.datable and its definition quotes:
"@period supplies a pointer to some location defining a named period of time within which the datable item is understood to have occurred."
but we don't have any examples of this use. This slipped given more important priorities just before the launch (see http://lists.village.virginia.edu/pipermail/tei-council/2007/008873.html).

Comments received

1977702: author and title to be added to att.canonical (when created)

<author> and <title> should be added to att.canonical when created (see bugs) to give them @key and @ref to point to authority list entries for this author or title.
att.canonical was requested to separate off @key and @ref from att.naming so that nameLink could not have @nymRef. The side effect of having @key and @ref as a separate class means they should be allowed any other places we want to provide such a reference (e.g. to authority name files or standard bibliographic databases)
-james

Comments received

2032879: permit looser content for physDesc

The content model for physdesc is (model.pLike+ | model.physDescPart_sequence_optional), which enforces the rule that physical description must either be entirely "unstructured" or entirely composed of specialized model.physDescPart elements. Though reasonable, this is a real problem for large conversion projects where some parts of the input text can definitely be assigned to one of the specialized elements, and other parts cannot. The only option at present is to treat the whole of the input as unstructured, which loses information unnecessarily. The proposal is to relax the content model slightly so as to permit an initial sequence of paragraphs: (model.pLike*, model.physDescPart_sequence_optional)

Comments received

2055116: Add typeDesc, analogous to handDesc

A number of projects cataloguing early print material and incunables have reported that the current msdescription module meets most of their requirements, albeit with some grimaces about the names of the elements. It has been suggested that it would be desirable in the medium term to try to generalise the "ms*" elements into "text-bearing-object*".
This proposal is one of two aimed to meet the most urgent needs so far identified. It is to define a new typeDesc element, analagous to handDesc, and as an alternative to it, is needed to contain descriptions of the typographic features of a printed source, within the physDesc.
See further discussion on TEI Council list 2008-08-05 et seq.

2055122: Permit titlepage elements within msItem and msContents

A number of projects cataloguing early print material and incunables have reported that the current msdescription module meets most of their requirements, albeit with some grimaces about the names of the elements. It has been suggested that it would be desirable in the medium term to try to generalise the "ms*" elements into "text-bearing-object*".
This proposal is one of two aimed to meet the most urgent needs so far identified. It is to permit the elements docAuthor, docDate, docImprint, and docTitle (currently permitted only within a titlePage) within msItem and msContents.
See further discussion on TEI Council list 2008-08-05 et seq.

Comments received

2055820: change content model of <w>

There is long standing discontent about the content model of the model.segLike elements <m> , <w>, <phr>, and <cl>. These are intended to be specialisations of <seg> (which is also a member of the model.segLike class). However, since <m> and <w> are meant to be used for segmentation at or below the single "word" level, they have different content models. Specifically, these two permit a mixture of text, model.gLike, model.global, and model.segLike elements only, whereas the others contain macro.paraContent. The intention is to prevent nonsense like the introduction of a <list> within a word, but the cost is that useful tags like <hi> or <am> are also not available. It's not unreasonable at all (as several have pointed out) to want to use such tags at a sublexical level; yet the only way to do so at present is to wrap the content of the <w> within a <seg> (which being a member of model.segLike is permitted!). So you cannot say <w>M<am>.</am></w> -- but you can say <w><seg>M<am>.</am></seg></w>. Which just looks silly.
There seem to be two possible solutions (if you agree that the status quo is broken)
a. change <w> and <m> to have macro.paraContent, like all the other model.segLike elements
b. permit these two to contain an appropriate subset of "sublexical" elements, either as well as or instead of model.segLike
(see also discussion on TEI council list, starting at http://lists.village.virginia.edu/pipermail/tei-council/2008/009883.html)
My preference would be for the latter. I suggest that the appropriate subset would consist of - current members of model.pPart.edit - current members of model.hiLike Whether this should consitute a new "sublexical" class is probably best left to the next revision of the class system, however.

Comments received

2055880: Revise description of <desc>

This currently states "contains a brief description of the intended usage,purpose, or application of its parent element.". However we have since broadened its scope by using it e.g. within <event> to mean something like "contains a brief description of the entity documented by its parent element". I think this is close enough not to warrant a new element, and propose the following text as a replacement "contains a brief description of the entity documented by its parent element, including its intended usage, purpose, or application where this is appropriate"
or maybe drop everything from the comma on!
See discussion at http://lists.village.virginia.edu/pipermail/tei-council/2008/009828.html

AMBER items

2033641: erroneous "Empty element" statement in documentation

I spotted a mistake in the HTML documentation of the <datatype> element (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-datatype.html). The field labeled "May contain" states that it is an "Empty element", whereas the actual content declaration reads:
<rng:zeroOrMore> <rng:group> <rng:ref name="macro.schemaPattern"/> </rng:group> </rng:zeroOrMore>
I suppose this is a bug in the tagdocs.xsl stylesheet somewhere (probably the "generateChildren" template?).

1925125: Review usage and precision of @extent

See debate on TEI-L 20-22 feb 08

Comments received

2055864: Remove redundant iso-* attributes

The iso-when attribute can contain a single string which represents any or all of the features represented by attributes iso-from iso-to or iso-dur (this is not however true of the equivalent w3c-* attributes). I propose therefore that we retain only the iso-when attribute and explicitly add it as an alternative to the combination of w3c attributes. This would both avoid the need to define two attributes classes and make explicit that the iso dating mechanism is intended to be used as an alternative to the w3c one, not as a supplement to it.
See brief discussion at http://lists.village.virginia.edu/pipermail/tei-council/2008/009879.html

2055891: Placement of schematron rules

At various times it's been suggested that an ODD specification should include somewhere additional constraints on the usage of an element expressed in terms of schematron rules. It's not however clear where within an elementSpec these rules should be supplied, or if. We need to decide this for our own internal use, but it would also be helpful at least to document the options in TD, or possibly to provide a definitive location in a revision of the content model. See discussion at http://lists.village.virginia.edu/pipermail/tei-council/2008/009798.html and preceding thread.

Comments received

RED items

1891589: sequenceOptional (etc.?) disrupt 'may contain' ref. info

Some reference pages where the content model includes a model class which s _sequenceOptional (etc.) then mean that the proper contents of that element are not listed in the 'May Contain' section of the element's reference page.
See for example the reference page for 'physDesc' where msDescription should mean that it can contain: accMat additions bindingDesc decoDesc handDesc musicNotation objectDesc sealDesc through containing model.physDescPart_sequenceOptional.
Probable Cause: XSLT not processing _sequenceOptional (check also other variations).

2021933: <egXML> content model

The TEI guidelines unambiguously state that <egXML> should be used to contain XML example fragments: eg: Section 22.4.2 Exemplification of Components (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDeg) quotes the description for <egXML>: "egXML (example of XML) contains a single well-formed XML fragment demonstrating the use of some XML element or attribute, in which the egXML element itself functions as the root element. " and further states explicitly that "[a]n egXML element should not be used to tag non-XML examples: the general purpose eg or q elements should be used for such purposes."
Yet, <egXML> is formally specified to contain only text (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-egXML.html):
<rng:element name="egXML"> <rng:ref name="att.global.attributes"/> <rng:ref name="att.xmlspace.attributes"/> <rng:text/> </rng:element>
Which seems obviously wrong to me. James Cummings pointed me to a modified definition of <egXML> in http://www.tei-c.org/release/xml/tei/custom/odd/tei_odds.odd:
<elementSpec module="tagdocs" ns="http://www.tei-c.org/ns/Examples" usage="mwa" ident="egXML" mode="change"> <content> <oneOrMore xmlns="http://relaxng.org/ns/structure/1.0"> <choice> <text/> <ref name="anyTEI"/> </choice> </oneOrMore> </content> </elementSpec>
Where "anyTEI" is specified as a macro listing all TEI elements. There are two problems with this definition as well: 1. all examples in the distributed TEI odd files should be properly namespaced. Instead of
<egXML xmlns="http://www.tei-c.org/ns/Examples"> <p>I fully appreciate Gen. Pope's splendid achievements with their invaluable results; but you must know that Major Generalships in the Regular Army, are not as plenty as blackberries. </p> </egXML>
it should be
<eg:egXML xmlns:eg="http://www.tei-c.org/ns/Examples"> <p>I fully appreciate Gen. Pope's splendid achievements with their invaluable results; but you must know that Major Generalships in the Regular Army, are not as plenty as blackberries. </p> </eg:egXML>
2. Even then, this content model would be too limited w.r.t. the prose description that "any well-formed XML fragment" should be allowed in <egXML>. It appears that such a general content model can be expressed in Relax NG without much problems[1].
To round up, I suggest that 1. Minimally, the general content model of <egXML> should be replaced with the adapted definition from tei_odds.odd. 2. Optimally, the general content model of <egXML> should be relaxed to allow for any XML element 3. Optionally, the examples TEI ODD files should be recoded with proper namespaces.
Ron Van den Branden
==== [1] examples of such definitions: * http://www.relaxng.org/tutorial-20011203.html#IDAFLZR * http://blog.subterfusion.net/2008/accepting-any-element-in-relaxng/

Comments received

1900115: Expanding placement options for figure, bibl, meeting

The following relates to what started me reading the guidelines--trying to be able to follow the discussions so as to try to solve the few problems we have in getting our formerly P4 documents to validate. The following are the only essential barriers we have, and I wonder whether this might also be an issue for others too possibly. I have some more ideas such as those shared during the course of discussing the documentation, but which I plan on holding of on submitting (if you even would like ideas which are not immediately needed) since it is only this request which is essential for us.)
1) In closer (via divBottom?): figure, bibl, meeting 2) In byline (via titlepagePart, pLike.front, divTop, divBottom, or divWrapper?): figure, bibl, meeting 3) In docTitle (via titlepagePart, pLike.front?): figure 4) In bibl (via inter?): figure 5) In opener (via divTop?): meeting 6) Allow <figure> after a closer (as in a div3) (via divBottom or global?)
We'd also like to see <meeting> in running prose (where I think <event> would also be useful). The requests for <meeting>, however, are not as critical for us, since we can use <name> if necessary, but those pertaining to the placement of <figure> and <bibl> are.
Would adding <meeting> and/or model.biblLike (bibl) to model.phrase, and/or changing model.inter to work inside of divBottom/divTop/global/pLike.front work? Sorry, I still have little understanding of the class system, but just wanted to offer something.
Please let me know if there any other details I should supply.
Brett

Comments received

1925127: Provide discussion of taxonomical names

Provide an example (at least) showing how to markup taxonomical names such as those of animals and plants. Consider ways of adding more specialised tags in due course. See further discussion on TEI-L 17-2-08

Comments received

1933198: <precision> element needed

In the discussion on the addition of @precision attribute (see #1721365), it emerged that for this to be fully useful, we would need a <precision/> element parallel with the <certainty/> element (with @locus, @target, @degree, etc.). Possibly some discussion of this is needed. (It wouldn't need @assertedValue, for example.) Opening this as a new request to this discussion can be taken forward.

1933481: ODD needs a way to indicate deprecation at next major releas

ODD needs a way to indicate that an element/attribute/class/module will be deprecated at the next major Px release of the Guidelines.

1934586: Chapter Revision: Critical Apparatus

There is a general consensus that at some time there needs to be a substantial revision of the Critical Apparatus chapter and module. This is in order to bring it inline with modern electronic editorial theory and to enable various aspects which members of the TEI community desire. This tracker item isn't here to suggest what they are, but simple act as a reminder/focal-point for building a working group for considering this in detail.
-James

Comments received

1999652: Add @who to <quote>

Hi,
Since <quote> is only a more specific case of <q> and since, with @who in att.ascribed being described as indicating "the person, or group of people, to whom the element content is ascribed", I think it makes a lot of sense to allow @who on <quote> as well, since it must be common to wish to indicate to whom a quote is ascribed (even if no information in the text is present to be used to create a <cit> instead).
Of all the more specific versions of <q>, <quote> is probably the only one I see which needs @who, and as a more specific tag, I think it is more appropriate for a semantically-rich project to use <quote> than the more general <q> unless there is some reason for maintaining the ambiguity.
From a practical standpoint, being able to extract or otherwise query all of the quotations in a specific document by a specific person or organization is a very useful possibility.
Thanks!

2002418: New element = <clarification>?

At "Henrik Ibsen's Writings" we have created a new element to record the clarification phenomenon in manuscripts. Ibsen and his copyists some times clarify words or letters either by writing upon the already written word/letters or by repeating the word/letters offline. We encode these instances of repeating the same for the purpose of clarification, like this:
<clarification hand="HI" place="inline">Henrik</clarification>
<clarification hand="HI" place="offline">Henrik</clarification>
We believe this is a well known phenomenon for manuscript transcribers, and we think it would be a useful addition to chapter 11 "Representation of Primary Sources".
Please contact Ellen Nessheim Wiger (e.n.wiger@ibsen.uio.no) at Henrik Ibsen's Writings, if you have any questions or remarks.

2025561: parent attribute class: cramped display

In the reference section when we have a parent attributed class, it is displayed without space attached to the child attribute class.
Do we actually need to have the parent attribute class there at all? May be we do, but then we should have double brackets:
e.g. att.datable (att.datable.w3c (@period, @when, @notBefore, @notAfter, @from, @to) att.datable.iso (@when-iso, @notBefore-iso, @notAfter-iso, @from-iso, @to-iso))

Comments received