[tei-council] image encoding comments

[Syd Bauman]

AK> It is past the due date but I had read the P5 14.9 and had no
AK> concerns at that time.

Thank you.


SR> there is an awful lot of redundancy in the TEI. Yes,
SR> <tei:graphic> is probably syntactic sugar for
SR> <svg><image/></svg>, but so is <html:a> or even <html:object>,
SR> no? sometimes one wants simpler notations.

This is, I think, a strong argument in favor of <tei:graphic>. 


SR> My problem with SVG is that once you allow the SVG stuff in, you
SR> allow it all in, and that has problems for implementation. Since
SR> most people don't have SVG enabled in their browser, you have to
SR> dumb down to plain (X)HTML, which is hard if people hurl in huge
SR> gobs of complex SVG.

I don't understand how this is an argument against letting "SVG stuff
in" at all.
* if your browser can't show you SVG, does it matter whether the SVG
  is encoded in-line or in a separate document? either way, you can't
  see it.
* besides, TEI is not, and should not be, restricted by the
  capabilities of current toys


JC> Instead it is the idea of introducing yet another namespace into
JC> TEI at all. I love that with P5 we *can* include other
JC> namespaces. Currently we use the TEI namespace, the TEI Examples
JC> namespace, the XML namespace and in our ODDs the RelaxNG
JC> namespace. But I think we should try to keep it only to this if
JC> possible.

This is, I think, a reasonable argument against including SVG in TEI
P5. However, it is directly counter to a principle of P5 development
that Council came to at its 2002-01 meeting at KCL. Namely, not to do
things that others have developed standards for. That is, we agreed
that if there was some standard out there that covered an area of
encoding, we should seriously consider its adoption before going off
and making our own version. We did not explicitly say so at the time,
but using others' standards will mean using other namespaces.

Now obviously, this is just a guiding principle, not the law of the
land (after all, there is some other markup system out there that
does most everything we do -- wouldn't want to have a TEI document
that consists of <xhtml:p> and <docbook:list>, etc. would we?), but
nonetheless, deserves some consideration here.


CW> I am with you here. To me, you should be able to do basic things
CW> with tei:graphic, but should also be shown in the guidelines how
CW> to get the big iron out with SVG.

I'm not sure if you intend the big iron to be part of the TEI or a
customization. If it's a customization, should the discussion be in
the TEI Guidelines themselves or in an ancillary document? 


I just don't think

| <TEI xmlns="http://www.tei-c.org/ns/1.0"
|     xmlns:svg="http://www.w3.org/2000/svg"
|     xmlns:xl="http://www.w3.org/1999/xlink">
| <!-- ... -->
|             <figure>
|                 <svg:image xl:href="./duck.jpg" width="30mm" height="90mm"/>
|             </figure>

is all that much harder than

| <TEI xmlns="http://www.tei-c.org/ns/1.0">
| <!-- ... -->
|             <figure>
|                 <graphic url="./duck.jpg" width="30mm" height="90mm"/>
|             </figure>

especially since most the difference is in the namespace
declarations, which will almost always be cut-and-pasted.

I will say, however, that I am quite distressed to find that width=
and height= are required attributes of <svg:image>.


SR> There is also the possibility that <graphic> needs some changes,
SR> in light of the discussion.

What changes do you have in mind? Nothing jumps to my mind except
perhaps that we should consider using target= instead of url=.