This document summarizes informally the errors reported to date in TEI P3. At the time this version was prepared, the list was complete as to problem reports on TEI-L and TEI-TECH through the end of April 1996. It may omit some errors reported privately.
The reports are grouped into DTD errors, typographic errors, and new work items. The latter section includes errors which appeared to the authors not to be corrigible within the framework of TEI editorial policy -- they must be referred to the Technical Review Committee or a work group for consideration, since there is no single obvious solution. The section of new work items includes only topics arising from error reports; it does not include topics not arising from error reports.
The inclusion of a report in the section of new work items indicates a belief that the error in question is not a corrigible error; the inclusion of a report in the section of errors, however, does not necessarily indicate a belief that it is corrigible.
In this section, entries have the following format:
Errors reported on TEI-L and TEI-TECH, or reported by the editors, are these:
<app>
<lem>Experience</lem>
<rdg>Experiment</rdg><wit>Cp Pw</wit></rdg>
<rdg>Eriment</rdg><wit>Ra2</wit></rdg>
</app>
but, to my considerable surprise, you can't do this:
<app>
<lem>Experience</lem><wit>Hg El</wit>
<rdg>Experiment</rdg><wit>Cp Pw</wit></rdg>
<rdg>Eriment</rdg><wit>Ra2</wit></rdg>
</app>
This looks to me like a plain oversight. The dtd content model for app should
say something like
(lem, (rdg?, wit?) )
not
(lem, (rdg, wit?) )
as it now says.<handList> <hand id=Q hand=Q> <hand id=Mb hand=Mb> </handList>This parsed, but it's kind of silly. [Accepted as bug by editors, 1995-01-05.]
headword = adhere
related-entry = adhesive
part-of-speech = adjective ("adhesive" the adjective)
part-of-speech = noun ("adhesive" the noun)
We would like to handle this situation by nesting two <hom>
elements within the
<re> element. And the TEI "Guidelines" document text seems
to imply that that
would be ok. But the TEI DTD fragment appears to
forbid nesting <hom> within
<re>. (1995-03-09 CMSMcQ agrees mismatch between doc and
DTD is a bug, but says it's not clear which is right. To be
referred to TRC.)
...
<!ENTITY % admin 'INCLUDE' >
<![ %admin; [
<!ELEMENT %n.admin; - O (%paraContent;) >
<!ATTLIST %n.admin; %a.global;
type CDATA #IMPLIED
date CDATA %ISO-date
--must be
date %ISO-date #IMPLIED
--
resp CDATA #IMPLIED
TEIform CDATA 'admin' >
] ]>
...
1995-07-14 : Peter Flynn : :
<!-- Bodge to get round bug in TEI DTD, courtesy of LB --> <!ENTITY % x.data '%n.persName | %n.placeName | %n.orgName |'>
1995-10-18 Arjan Loeffen says of this "3) The fix, though acceptable in itself, is not acceptable to SGML, as it creates ambiguity in the content model of placeName (psgml accepts this?). This explained below for those interested."
foo bar</p><pb n=44><p>blort as well as<pb n=45>this</p>However, the Green Bible says of PB, "May occur within: [none]", which seems to imply that you can't put it anywhere at all! Indeed, trying to import text containing it into one editor causes some very interesting side-effects, like hanging MS-Windoze. <PB> must surely be permissible at any point? [Fixed 1994-09, according to LB 1995-08-18]
begin section
head ("ION: A MONODY")
page break
figure with figdesc
page break
head ("Ion: A Monody")
beginning of poem
We've fudged this sort of thing in several ways -- including a figure
in a head that's very close, creating a new division, dropping the
figure. Isn't what's needed here a floating element? Figures are
so rarely predictable with regard to structure. Am I just overlooking
something?1995-10-13 : Joe Wells : :
"Michael" == C M Sperberg-McQueen < U35395%uicvm@buacca.bu.edu > writes:
Just saw your posting on comp.text.sgml about marked sections, in which you say you have seen a grammar from TEI which gives inaccurate information about marked sections. Can you tell me more about this? The TEI has made a number of files available which can be construed as grammars; what file do you actually have? And in what way is it wrong? I would very much like to fix any errors you've found.
Hello, Michael,
This document:
Marked sections take the following forms (n.b. the marked section keywords
may be replaced by parameter entity references).
/* Marked Sections */ // Cf. 97-100
msignore ::= '<![' ignore '[' anything ']]' || '>'
mscdata ::= '<![' kwcdata '[' chardata ']]' || '>'
msrcdata ::= '<![' kwrcdata '[' rchardata ']]' || '>'
msinclude ::= '<![' include '[' scandata ']]' || '>'
/* Marked Section keywords */
ignore ::= kwcdata 'IGNORE' kwcdata
| ignore 'IGNORE' kwcdata
kwcdata ::= kwrcdata 'CDATA' kwrcdata
| kwcdata 'CDATA' kwrcdata
kwrcdata ::= include 'CDATA' include
| kwrcdata 'CDATA' include
include ::= /* nothing */
| include 'INCLUDE'
| include 'TEMP'
/*
** Multiple keywords may appear; rank order is IGNORE,
** CDATA, RCDATA, INCLUDE. TEMP is also legal but has
** no effect.
*/
chardata ::= /* characters returned to parser as
character data, regardless of what
delimiters are present */
rchardata ::= /* characters scanned for entity references,
and then returned to parser as character
data, regardless of what other
delimiters are present */
scandata ::= /* characters scanned and returned to parser
as normal */
anything ::= /* characters scanned only for ']]' || '>' and not
returned to parser. */
Problems:
<<!>![ INCLUDE [ <foo> ] ]> </foo>
but it can not occur in the middle of a tag, like this:
<<!>![ INCLUDE [ <foo ] ]> > </foo>
1995-10-13 : CMSMcQ (reply to Wells) : :
1. The grammar does not allow the RCDATA keyword. This is clearly a typographical error. I assume the _kwrcdata_ production should mention RCDATA rather than CDATA.Correct; thanks.
2. The grammar does not allow the IGNORE keyword to occur without being accompanied by the CDATA and RCDATA keywords. Similarly, CDATA must be accompanied by RCDATA.Ouch. Incompetence on my part, or overreaching for brevity. It should read:
/* Marked Sections */ // Cf. 97-100
msignore ::= '<![' ignore '[' anything ']]' || '>'
mscdata ::= '<![' kwcdata '[' chardata ']]' || '>'
msrcdata ::= '<![' kwrcdata '[' rchardata ']]' || '>'
msinclude ::= '<![' include '[' scandata ']]' || '>'
/* Marked Section keywords */
ignore ::= noignore 'IGNORE' noignore
| ignore 'IGNORE' noignore
kwcdata ::= nocdata 'CDATA' nocdata
| kwcdata 'CDATA' nocdata
kwrcdata ::= norcdata 'RCDATA' norcdata
| kwrcdata 'RCDATA' norcdata
include ::= noincl 'INCLUDE' noincl
| include 'INCLUDE' noincl
noincl ::= /* nothing */
| noincl 'TEMP'
norcdata ::= include
| noincl
nocdata ::= kwrcdata
| norcdata
noignore ::= kwcdata
| nocdata
3. The production for _anything_ does not mention the fact that the characters are also scanned for '' are skipped.Bug -- it should mention it. I think the grammar reflects a faulty understanding of IGNORE marked sections at the time I wrote the grammar; it is interesting but not consoling to note that Intellitag and DynaText (among others) also have at various times shared this faulty grasp of the rules.
4. The production for _chardata_ fails to mention that _chardata_ can not include an occurrence of ']]>'. (This is an instance of a general problem throughout the grammar, not just here. For example, the STRING in an attribute value literal '"' STRING '"' can not contain a '"'. At least the grammar is consistent about failing to mention this kind of detail.)Yes. I suppose if this grammar is supposed to be free-standing, this kind of thing ought to be clearer. As it is, the grammar just waves its hands and says 'the lexical scanner handles it' without saying how -- in large part because I didn't want to stop to work out just how.
5. The production for _rchardata_ fails to mention any of the subtle details of general entity expansion. For example, an entity that expands to ']]>' does not terminate the marked section. While sensible, there is no possible way to figure this out from the grammar as given.This, at least, was a conscious decision (I think) to elide all details of entity expansion, to make the grammar easier to understand. But something should probably be changed here; either the entity expansion rules need to be covered after all, or a clear statement needs to be added warning about interactions between the grammar as presented and the entity expansion rules.
Or the lexical scanner needs to be presented in full detail.
6. The production for _scandata_ fails to mention any of the details of where the terminating ']]>' can occur. For example, it can occur in the middle of an element, like this:Correct; handled invisibly and magically by the lexical scanner.<<!>![ INCLUDE [ <foo> ] ]> </foo>but it can not occur in the middle of a tag, like this:<<!>![ INCLUDE [ <foo ] ]> > </foo>There is no possible way to figure this out from the grammar as given.
1996- : LB : : The attribute RESP is defined inconsistently.
Here is an alphabetical list of the elements for which RESP is explicitly defined, and the value it has in each(generated by hand so I may have missed some):
ABBR IDREF ADD IDREF ADDSPAN IDREF CORR CDATA (though it says it must be an identifier) DAMAGE IDREF DEL IDREF DELSPAN IDREF EXPAN IDREF GAP IDREF HAND CDATA HANDSHIFT IDREF NOTE CDATA ORIG CDATA REG CDATA RESPONS CDATA RESTORE IDREF SIC IDREF SPACE CDATA UNCLEAR CDATAIn addition, members of the pointer class have a RESP attribute, defined as CDATA.
To make things more interesting, members of the EDIT class (add, corr, del, gap, orig and reg) also have a RESP attribute, defined as IDREF. There is a note which says that this applies "only when the additional tag set for transcription of primary sources is used" but I don't understand how or if that works.
I'm now tending to come down more on the IDREF side of the fence, by the way. Shouldnt it target the identifier of a <respStmt> rather than some arbitrary list item though?
Many of you have come across <docTitle>s split by <byline>s.
For example
Cats and the Mice They Catch by Jane CatWomon A Disgustingly Thorough Illustrated Manual Wherein Blood, Guts, and Squeaking Are Extensively DiscussedSyd suggests handling such things using linking: (for more information on linking, see the example on p. 289 and see chapter 14, Linking, Segmenta- tion, and Alignment, esp. section 14.7, "Aggregation," in P3).
<titlePage> <docTitle id=DT1 next=DT2> <titlePart type=main> Cats and the Mice They Catch </titlePart> </docTitle> <byline> by <docAuthor>Jane CatWomon</docAuthor> </byline> <docTitle id=DT2 prev=DT1> <titlePart type=sub> A Disgustingly Thorough Illustrated Manual </titlePart> <titlePart type=desc> Wherein Blood, Guts, and Squeaking Are Extensively Discussed </titlePart> </docTitle> </titlePage>
1996-04-05 : Arjan Loeffen (replying to preceding) :
In Message Wed, 3 Apr 1996 18:52:44 GMT+0100, Linda Elisabeth van den Brink ... writes:
>I have a question regarding the MET and RHYME attributes. I want to use >them, as suggested in the Guidelines (P3), with the DIV element. I read >in the Guidelines par. 9.4 that this is possible, if the verse base tag >set is in use. I have invoked the verse base tag set, and yet my parser >(sgmls) says, when it encounters a MET or RHYME attribute with a DIV >element: "attribute not defined for this element".
Linda, I'll tell you this way what I think, so others may comment on it.
I guess this is a design error that has its effect on the DTD and the text of the guidelines. For example, the fragment
<!-- P3 9.4.1. Sample Metrical Analyses. Guidelines pg. 261 -->
<text>
<front> ... </front>
<body met='-+|-+|-+|-+|-+/' rhyme='aa'>
<lg1 n=1 type="verse paragraph">
<l>'Tis hard to say, if greater Want of Skill</l>
<l>Appear in <hi>Writing</> or in <hi>Judging</hi> ill;</l>
<l>But, of the two, less dang'rous is th'Offence,</l>
<l>To tire our <hi>Patience</hi>, than mis-lead
our <hi>Sense</hi>:</l>
<!-- ... -->
</body>
</text>
does not parse with the P3 base tag set for verse (as noted by you). The
explanatory text states that <div> may bear the a.metrical attributes,
which is incorrect with regards to the class description on p. 797-798
and the DTD made available. I think the class description and the DTD
should be reconsidered.
The meaning of the metrical attributes on division elements, if I understand correctly, is to express that the complete division follows the metrical parameters specified unless overridden by a sub-division (or lg, for that matter). Specifying e.g. a rhyme= on such an element would tell the receiver that the mass of the division is in rhyme X, though parts may deviate from this. The guidelines' class and element descriptions only assume l, lg, lg1...5 are members of the metrical class. This set should be expanded to div's (and seg's) too if the many examples and text of the guidelines show the intent of the designers.
We could propose a correction (not a local extension): add %a.metrical to the attribute definition list declaration of the structural elements, i.e. in TEISTR2.DTD, e.g.:
<!ATTLIST %n.div; %a.global;
%a.declaring;
%a.divn;
%a.metrical; -- added for verse texts --
TEIform CDATA 'div' >
Here we assume that only metrical info would have to be added to such
elements. However, this does not seem a valid approach. <div> is used
in all tag sets as a common structuring element. When you do this you
force _all_ divisions to imply three attributes:
<!ENTITY % a.metrical '
met CDATA %INHERITED
real CDATA #IMPLIED
rhyme CDATA #IMPLIED' >
This would not be a syntactical (SGML) problem, but it is conceptually
incorrect. Actually all attributes are implied, so SGML parsers will not
stumble over it. But if you take %inherited for what it's intended to be
you do have a problem, as the highest order <div>, the one highest in
the document tree, will have to specify a value for the met= attribute.
This would not only hold for a piece of poetry, but also for a print
dictionary or a novel. Which is clearly nonsense.
What we get here is something like a deadlock. <div>'s of the various types are declared such that they suit all tag sets, i.e. all derived DTD's. We could work out a construct that declares a 'default' a.metrical to be empty. This declaration would be overridden by the verse tag set. In that case, in a novel, you would not see the metrical attributes. In verse, you would, and you would be forced to specify a most general value for met=.
However, in this way you break up the class concept of the TEI. You cannot say that a class a.metrical 'exists' in verse, and 'does not exist' in prose, though in both text type descriptions the class is referenced by name. Simply because the class concept is not defined this way by the TEI. I'd call this a deadlock.
I may be wrong here. Maybe David Chrisholm or David Robey could react on this? They wrote an article in the Comp & Humanities special TEI issue on the subject. They use the 'metrical division' in many examples (note however that they in several places deviate from/extend the P3 recommendations).
Because the <gi>link<gi> and <gi>corresp</gi> ...
But in fact, when I look at the P3X file, it is encoded correctly:
Because the <gi>link</gi> and <gi>corresp</gi> elements ...
<!ENTITY % n.participant "participant" >My current solution: none.
...
<!DOCTYPE TEI.2 system 'tei2.dtd' [
<!-- declare an external entity for the wsd -->
<!-- must be fsd -->
<!ENTITY myFeatures SYSTEM 'myfeat.fsd' SUBDOC >
]>
<tei.2>
...
</tei.2>
<omit extent='approx 10 sylls' reason='passing truck'>" TEI Guidelines, p. 320.
This section lists some cosmetic changes which should be made if possible during the preparation for the corrected reprint. All items were identified by CMSMcQ.
This section is emphatically not complete; it merely lists some items reported as errors, which the authors of this summary prefer to classify as suggestions for further work.
<app>
<lem>Experience</lem>
<rdg>Experiment</rdg><wit>Cp Pw</wit></rdg>
<rdg>Eriment</rdg><wit>Ra2</wit></rdg>
<lem>Experience though</lem>
<rdg>Something else</rdg><wit>Xx</rdg>
</app
That is: each <app> element may contain just one <lem>,
with its accompanying <rdg> and <wit> elements etc. In
some circumstances this could be decidedly inconvenient. It means,
for example, that we cannot contain in the one <app> element
BOTH the variants on a particular word AND all the variants on phrases
beginning with that word. You could argue that no-one should ever
want to do such a thing. Well, I want to do this: in the ctp
apparatus we want to link from any one word in the master text to
every variant -- including phrases -- on that word and on phrases
beginning with that word. Altering the content model of <app>
to
<app -0 ((lem, (rdg?, wit?) )+ )>would allow me to have several lem/rdg/wit sequences embedded in the one <app>.
<div> <table>this is an inter element</table> </div>just as you can have
<div> <p>this is a paragraph</p> </div>Well, you can't. The same applies for all the inter elements which don't happen to be members of the 'common' class, etc. I found this out when I wanted <app> to appear directly within divs, and thought I could achieve this just by adding it to the inter class. Indeed, it is actually quite clear from the description of inter in the tagdoc section that it cannot sit directly within div, div0, etc: these are not included in the list of elements in which inter elements may nest. This simply cannot be right. All members of the analogous hqinter class can indeed occur alongside p etc, directly within divs. Am I the first to spot this? Do I get a dollar? How did this mistake happen? I found myself perpetually getting lost in the maze of element classes used to organize the tei entities: we have common, various inters, lots of components and component.seqs, all of which share (allegedly, in the case of inter) the ability to sit both within and beside <p> and analogous elements. No doubt there are good reasons for this apparent overlapping. The behaviour of <stage>, and the definition of the common class (P3 p. 772) seem especially odd: obviously stage directions need to appear both within and between <p> and the like. And so it is defined as one of the inter elements. But it does NOT get its ability to sit between <p>s from this definition, as one might expect. Rather, it gets it from being included, very peculiarly, in the definition for the common class:
<!ENTITY % m.common '%x.common %m.bibl; | %m.chunk; |
%m.hqinter; | %m.lists; | %m.notes; | stage' >
This is pretty odd: every other member of this class is a group of
elements (bibls, chunks, etc) and <stage> appears rather tacked on. In
fact, exactly the same effect could have been achieved just by something
like the following:
<!ENTITY % m.common '%x.common %m.bibl; | %m.chunk; |
%m.hqinter; | %m.lists; | %m.notes; | %m.inter;' >
Because stage is part of inter, then it would have got exactly the same
behaviour as having it appear on its own. And what is more, then all the
other elements in the inter class -- figure, table, etc -- would also have
got the correct behaviour, or at least the behaviour specified for them in
the guidelines.But when I tried to modify the dtd with this definition
(using the tei approved method,of course) I got errors elsewhere, so that
quick fix at least won't work.<sourcedesc>as found</>or something of the sort, but no rationale is stated.
<div> <head>title for this list</head> <list> the list... </div>TEI won't let me do that: seems I have to have:
<div> <list> <head>title for this list </head> the items.. </list> </div>this seems somewhat restrictive to me.
place of publication: publisher, date
but the <publicationStmt> lays them out as
<publicationStmt>
<publisher>publisher's name</publisher>
<pubPlace>place of publication</pubPlace>
<date>date of publication</date>
</publicationStmt>
This complicates life when one is displaying this information.
[This is a flat-out error in specifying bibl elements. -CMSMcQ]1995-07-31 : Jean Veronis : I answered a question by Eric Peterson on TEI-L recently on "Verb Stem Notation etc." concerning the usage of the dictionary form pointer tags <oRef> and <oVar>.
My conclusion was that there was an oversight on the part of the dictionary group. We intended to make the form pointers part of <eg> only (entity %m.formPointers):
--file teidict2.dtd:
<!ELEMENT %n.eg; - O (%n.q; | %n.quote; | %n.cit;)+
+(%m.dictionaryParts
|
%m.formPointers)>
But the remark by Eric Peterson clearly shows that the form pointers can be needed anywhere in the entry and my suggestion was to place this item on the revision list.
However Eric noted that when he places <oRef> in places others than <eg>, his parser does not complain. I tried myself and Eric is right, and I found that fact extremely puzzling because %m.formPointers does not appear anywhere in the teidict2.dtd file, and is therefore not part of any other content model.
After some navigation in the files, following the parameter entities definitions, I found the solution, which might be of some interest to some of you.
<!ELEMENT %n.form; - - (%m.formInfo | %paraContent)+ >
<!ENTITY % paraContent '(#PCDATA | %m.phrase | %m.inter)*' >
<!ENTITY % m.phrase '%x.phrase %m.data; | %m.edit; |
%m.formPointers; | %m.hqphrase; | %m.loc; |
%m.phrase.verse; | %m.seg; | %m.sgmlKeywords; |
%n.formula; | %n.fw; | %n.handShift;' >
Therefore, the form pointers (entity %m.formPointers) can appear
anywhere in any phrase-level parts of dictionary entries.This is accidental but fortunate since we wanted, indeed, to revise the DTD to allow the form pointers anywhere in entries.
I would like to propose a revision that would accomplish this goal, but differently. The problems with the current solution are as follows:
<eg><oRef></eg>
which does not make much sense.
<!DOCTYPE tei.2 SYSTEM "tei2.dtd"
[
<!ENTITY % TEI.dictionaries 'INCLUDE'>
]>
<TEI.2>
<teiHeader>
<fileDesc>
<titleStmt>
<title> ... </title>
</titleStmt>
<publicationStmt>
<p> ... </p>
</publicationStmt>
<sourceDesc>
<p> ... </p>
</sourceDesc>
</fileDesc>
</teiHeader>
<text>
<body>
<p>This is <emph>not</emph> a dictionary.</p>
<p>I just wanted to quote the following entry in my paper:</p>
<entry>
<form>blah<oref></form>
</entry>
<p>And here my paper continues...</>
<p>But I am now allowed to have <oRef> anywhere!</p>
</body>
</text>
</TEI.2>
I can think of two ways to solve the problem, that is, allow the form pointers everywhere in dictionary entries, and nowhere outside. In both cases, %m.phrase must be redefined as:
<!ENTITY % m.phrase '%x.phrase %m.data; | %m.edit; |
%m.hqphrase; | %m.loc; |
%m.phrase.verse; | %m.seg; | %m.sgmlKeywords; |
%n.formula; | %n.fw; | %n.handShift;' >
(i.e. it should not contain %m.formPointers).
Solution 1: Define a special class %dictParaContent; instead of %paraContent, that would be allowed to contain %m.formPointers, and use it everywhere in dictionary entries instead of %paraContent.
Solution 2: Keep %paraContent; as it is, but redefine <entry> (and also <entryFree>) to contain %m.formPointers as an inclusion:
<!ELEMENT %n.entry; - O (%n.hom; | %n.sense; |
%m.dictionaryTopLevel)+
+(anchor|%m.formPointers)
>
<!ATTLIST %n.entry; %a.global;
%a.entries;
TEIform CDATA 'entry' >
<s>Few dictionary makers are likely to forget Dr. Johnson's description of the lexicographer as <q>a harmless drudge</q>.</s>This seems to be a bug, especially since several elements that can appear in <s> can contain <q>. Is this right?
1995-07-29 : CMSMcQ (in reply to Nancy Ide) "So far as we can tell, the <s> tag cannot contain the <q> tag, except indirectly (e.g., <s><hi><q>...). This is clear in the definition of <s> in TEI LITE, and seems also to tbe true in TEI.2."
Yes. TEI Lite does not modify the main DTD in this respect, and neither DTD allows Q or other inter-level elements (such as NOTE and LIST) to occur within elements defined as containing %phrase.seq -- only within elements defined as containing %paraContent. "We have lots of cases where we had intended to use <q> inside <s>. In fact, you can imagine one of the examples in the TEI LITE document could be encoded as ... This seems to be a bug, especially since several elements that can appear in <s> can contain <q>. Is this right?" This may or may not be unwise (I am inclined to think your example shows it probably is) but I am not sure it is a 'corrigible error' in the sense of DTD maintenance, because I believe that S, and a large-ish number of other elements, were intentionally defined as containing %phrase.seq in order to keep inter-level elements out of them. In general, I think this is unwise and when I could I argued against it, but having lost the argument I cannot now claim there was no argument and the error is a mere slip.
Which means, for the TEI, that I'll refer your query to the technical review committee for action, along with other similar suggestions for changes. For you, it means that you will need to modify the declaration of S to allow interlevel elements.
To do this, include the following line in your TEI.extensions.ent file:
<!ENTITY s 'IGNORE' >and the following in your TEI.extensions.dtd file:
<!ELEMENT %n.s; - - (%paraContent) -(s) >
<!ATTLIST %n.s; %a.global;
%a.seg;
TEIform CDATA 's' >
(If you don't know off hand what I mean by 'your TEI.extensions.ent file'
and 'your TEI.extensions.dtd file', re-read the discussions of DTD
modification in the chapter on the structure of the DTD and on modifying
the TEI DTD.)
Or you could take bold action and mess with the declaration of phrase.seq, which would change the behavior of all the elements declared as containing only phrases -- but which is likely to be cumbersome and slightly error-prone, particularly in the presence of other DTD modifications. I'd recommend not modifying phrase.seq unless you do it very carefully and ensure that your modified declaration can pick up any x-dot entity declarations provided in a document instance.
<list>
<item><label>For Guatemala</label>
<list>
<item><signed>Emilio Flores</signed></item>
<item><signed>Hernando Cardoza</signed></item></list>
<date>May 2, 1950</date></item> . . .
and so forth.
My current solution for this is using <name> where I have
<signed> above, and then givng a "type" attribute for the whole
list that tells you it is a list of signatures. This doesn't seem
quite right. I know I could extend the DTD to allow this use of
<signed>, I'm just wondering if there is some reason why things
were set up not to allow it to begin with.1996-03-26 : Carole E. Mah :
I'll re-state my interest in making TYPE part of a.global.
There are five interesting back-and-forths on this on TEI-L, starting in TEI-L LOG9601, the fifteenth posting for that month, entitled "Time to make 'type' attribute global?" by David Megginson; four relevant posts directly follow it.
Here are the elements to which we added TYPE:
%n.analytic; /* could be solved by revamping whole TEIHeader */
%n.bibl; /* ditto */
%n.monogr; /* ditto */
%n.epigraph; /* we're thinking of dropping it from this one */
%n.hi;
So on this front the main course of action, if the Working Group decides NOT to add TYPE, is to PLEA for a revamping of the TEI Header, since most of the TYPEs we added were hacks to make up for an inadequate TEI Header spec. on the part of the Guidelines.
[1]
Actually, I found 27 elements with this problem, but I found
those in a copy of p3reftag.ref downloaded back in May 94, and
have not checked against newer versions, green books, nor CD-ROM.
The elements are: alt, altgrp, bloc, c, cl, day, figdesc, interp,
interpgp, join, joingrp, link, linkgrp, m, orgdivn, orgname,
orgtype, phr, region, respons, span, spangrp, timeline, w, when,
xptr, and year.
[return to text]
[2]
This discrepency discovered by Carole Mah.
[return to text]