[tei-council] image encoding comments

James Cummings James.Cummings at computing-services.oxford.ac.uk
Mon Oct 2 06:15:10 EDT 2006


Syd Bauman wrote:
> 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.

I agree that as a guiding principle it is good not to reinvent the wheel.  I was
not on council at the 2002-01 meeting, so don't know the discussion that
accompanied it.  I'm all in favour of using ISO standard datatypes, for example,
as part of the TEI.  And while this is a good guiding principle, it does not
necessarily mean incorporating these external schemas into the TEI. The TEI
Guidelines give an adequate basic method of referencing images which most people
will be happy with.  The need for the complexity of SVG, as useful as it is, is
probably limited.  I agree that we should not reinvent the wheel, but provide a
basic method of doing whatever these external schemas do, and then document the
process of inclusion of such externally controlled schemas as customisations.
I'm not against the TEI sanctioning or suggesting their use, and providing the
customisations necessary to do so, but I think they should not be included in
tei_all.

> 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.

If docbook:list gave us some significant benefit over TEI list, and it is of
such benefit that we would adopt it wholesale instead of simply adding those
useful features to tei:list, then I would still say it should be added by
customisation.

> 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 see no reason why the TEI Guidelines proper can't discuss possible
customisations, in fact I'd encourage it.  Discussions along the lines of "This
is how the TEI does this and it is sufficient for most people, however, if your
needs are significantly more complex, then here is the external schema we would
recommend using, and if you are going to use it, then here is the recommended
method to do so." I.e. that such external schemas are not part of the TEI, but
we recognise some people might need them and if they are going to use them would
like to suggest the best way to do so, to avoid increasing distancing of
individual TEI-based schema implementations.

> 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">
>
> is all that much harder than
> 
> | <TEI xmlns="http://www.tei-c.org/ns/1.0">

That is because you understand namespaces.  I think this is much more difficult
on a whole range of levels.  I think it is better, on a technical level, to
avoid as much fragmentation as possible in the heart of the TEI specification.

One of my reasons for objecting is entirely non-technical, that is that it makes
selling the concept of the TEI that much more difficult.  If people have:
> | <TEI xmlns="http://www.tei-c.org/ns/1.0">
in documents, then they know they are using this wonderful thing called the TEI,
they and their funders feel safe and happy, and the perception is that things
are basically straightforward.  If they have:
> | <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">
then suddenly they're doing something difficult.  Whether in practice it is or
isn't difficult doesn't matter as much as the perception.  If SVG, why not
hundreds of other schemas?  If the TEI is this amorphous multivalent construct
which simply suggests other people's specifications whenever encoding gets
difficult, then not only will be harder to convince people to use it, but why oh
why would they do something like budget money to become members of the
consortium?  Ok, I know I'm exaggerating here and overreacting, but I can see
people becoming even more confused about what makes up the TEI.  I'm all for use
of other namespaces, and I'm happy for the TEI to suggest possibilities, give
examples, and even make it extremely easy to use them (i.e. tick box in Roma).
But all of that is something very different philosophically, I think, than
incorporating them as part of the TEI's schemas.

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

It has nothing to do with it in my mind.  I'm more worried about it
philosophically and with the extra barrier to use it causes in implementation.

-James
-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk



More information about the tei-council mailing list