Lou Burnard wrote:
>I propose to address these concerns as follows:
>1. Introduce a new core element called <graphic> with a URL attribute
>(or whatever the TEI Workgroup on Standoff finally decides it should be
this seems unequivocally a good thing, to have an element
whose purpose is to include some external picture. However:
is "<graphic>" right? would one not use the same thing to embed
a video or sound clip, or a flash thang? HTML calls this an <object>,
and when I look at the HTML spec, I wonder if this is not
something we should leave to (X)HTML? Otherwise, won't we be involved
in feature creep as we add more attributes to match what they
provide? image maps, dimensions, scaling, mouse actions etc?
>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?)
>What I don't know is how to add an SVG element into the mix. Ideally, I
>would like to add <svg:something> to the tei.figContent class. Suggestions?
I'd like to generalize this <figure> to allow nested <figure> elements,
so <figure> would have a content model of
head?,figDesc?,figure+ | tei.figContent
allowing for people who want to make up a composite figure
from all sorts of components. this allows for each component
to have its metadata <head> and <figDesc>.
tei.figContent would be
eg | figText | graphic | svg:svg
by default, and could be extended as needed to