There are in fact 63 of them. I think at one point we thought these
references were not as useful as they seemed, and stopped putting them
in. But I will raise a ticket listing the missing ones and suggesting
they be supplied.
On 19/04/13 09:46, Tomaz Erjavec wrote:
> This does look like a bug. I also noticed that <line> doesn't have a pointer to the section in which it is discussed, which can of course be very useful and (almost) all other elements have this information. But not all - I've noticed some others without the link into the Guidelines, but, alas, didn't make a record. Still, it shouldn't be too hard to identify them automatically I think (//elementSpec[not(listRef)]) - fixing them would take a bit longer though..
> -----Original Message-----
> From: TEI (Text Encoding Initiative) public discussion list [mailto:[log in to unmask]] On Behalf Of Georg Vogeler
> Sent: Friday, April 19, 2013 10:09 AM
> To: [log in to unmask]
> Subject: [TEI-L] <g> in <line> not allowed?
> Dear list,
> when transcribing a text in a 'topographic' style, using the
> surface/zone/line model I recently came across a problem in the
> schema/data model which I'm not sure that it is intended: line seems to
> disallow a <g> element as content
> Thus a transcription of a medieval abbreviation like
> <line>... <g ref="#per-glyph">per</g> ... </line>
> isn't possible.
> From my point of view that doesn't make much sense, as when embedding
> the transcription with the facsimile I do that because I'm interested in
> encoding graphical observations, like glyphs so I would consider the
> current defintion of line (or g which as being longer part of the TEI
> element family maybe has an older right to be correct) as a bug. But
> maybe I missed the point of it?