In Message Wed, 3 Apr 1996 18:52:44 GMT+0100,
Linda Elisabeth van den Brink <[log in to unmask]> 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 -->
<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
<!-- ... -->
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.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
Arjan Loeffen, Humanities Computing, Faculty of Arts,
Utrecht University, The Netherlands.
++31+302536417 (voice work), ++31+206656463 (voice home)