> 1. Introduce a new core element called <graphic> with a URL attribute
> (or whatever the TEI Workgroup on Standoff finally decides it should
> be called).
> 2. Introduce a new wrapper element to hold text content of a graphic,
> called <figText>, with content model mle the current <figure>
> content model.
> 3. Introduce a new class tei.figContent, with members <graphic>,
> <eTree>, <eg> (or whatever we decide to call that thing), <figText>
> 4. Redefine the content model of <figure> to be (%(tei.figContent),
> figDesc?, head?)
If I understand you correctly, for the simple case, where in our current
documents we have
in your proposal we'd change this into (ignoring the issue of replacing
entities by URL's):
A few questions / remarks:
1. What you encode is perhaps not really a figure, but something like a
figureDiv: an area on the page with a head and a label of its own - and
of course, a graphic element. Or perhaps a graphic element isn't even
needed, and we could have something like extraDiv: an area outside of
the normal print flow, possibly used for a graphic, quite possibly also
for some textual additions.
2. In fact, an <eg> will generally contain (CDATA) text, won't it? I did
not understand it's inclusion in tei.figContent at first, but it makes
sense if your real concern is not the image but a separate region on the
3. Rather than having to change currently valid documents I would prefer
to optionally include figure elements in a new extraDiv element. This
extraDiv element would be an inter-level element, having for a content
model something like your tei.figContent. (I'm not an expert in the TEI
class system, I'm afraid).
4. A figText element to hold text transcribed from the figure would seem
a good idea, but...
5. and finally: like I suppose many others on this list, I spend part of
my working days explaining to people they should use durable public and
stable standards in their digitisation efforts, as it will help the
output of their efforts withstand the centuries (more or less). I
understand one shouldn't want to stop progress, but I also feel we
should do our utmost to keep valid constructions valid.
Supposedly people will not be forced to migrate to P5, but in practice
many people will have to do so, e.g.
- in order to have a single encoding standard in their projects
- because their favourite tool will no longer support P4
- because they don't want to maintain a double set of style sheets
My apologies if I misunderstood your proposal.