[tei-council] image encoding comments

[Dot Porter]

I like the idea of the TEI Guidelines including suggestions for other
standards to use (e.g. SVG) along with TEI when the TEI doesn't
include enough detail for a given project, also including one or two
*brief* examples of when you might want to consider using an
additional standard, and I really like the idea of making it easy to
add these other standards to a customization (through a tick-box in
Roma, as James suggests).

Dot

On 10/2/06, James Cummings
<James.Cummings at computing-services.oxford.ac.uk> wrote:
> 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
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>


-- 
***************************************
Dot Porter, University of Kentucky
#####
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
#####
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu
***************************************