[tei-council] [TEI-L] SV: TEI MIME type (fwd)
James.Cummings at oucs.ox.ac.uk
Wed Nov 25 06:24:54 EST 2009
For those new on the council list they may wish to read the
previous discussion in this at:
I mention it partly to remind people of the existence of the
public mail archive.
The general feeling then was that there wasn't enough of a strong
case for undertaking this. Although I accept the argument that
it might be good from a publicity and advocacy angle, what still
bothers me about it is the need to differentiate TEI as a
specific form of XML. (Indeed, one _could_ make the more
theoretical argument that TEI is separate from its markup format
and only chooses to use XML at the present moment like it chose
to use SGML previously and who-knows-what later.) There are
perfectly good ways to indicate that you want to use the TEI
Stylesheets in your XML document (XML stylesheet processing
instruction). The versioning of TEI with respect to mime types
also bothers me. If I say my document is application/tei+xml then
what does that really tell anyone? They could know that from the
root element or the namespace. It doesn't, for example, tell
them whether it is P4 or P5 or P5 1.3.0 vs P5 1.5.0 or P6 or P7.
It doesn't say that the document is TEI-Conformant, or
Conformable, or that it validates against this or that schema.
(Obviously there are other ways to indicate this.) I guess I'm
just not convinced it is worth the effort, and on reflection that
its existence might even be detrimental. Perhaps in defining
this people will take it to assume one version or schema or
something and build software that uses the existence of this
mime-type as an indication of something it isn't. As for
differentiation when embedding TEI inside other XML vocabularies,
isn't that what namespaces are meant to be for? The REST example
is a good one, but hardly a reason for doing it by itself. It
isn't that I'm whole-heartedly against the idea, I've just not
yet been convinced that it is really useful.
However, arguing against myself, I've just gone and read a bit of
the HTTP spec and you can include arbitrary parameters after mime
types in HTTP Accept headers. So one could for example do:
and such things. If one were to have a TEI internet mime type
would it seem reasonable to make recommendations towards these as
well? Looks terribly icky though to me.
Laurent Romary wrote:
> There seem to be a shift of opinion on this. May I ask whether there
> are strong disagreements that have not been expressed so far, and if
> not (let's say by the end of the week) do like David suggests here.
> Decision would be (if I understood correctly): go for a application/tei
> +xml application
> Le 24 nov. 09 à 17:20, David Sewell a écrit :
>> Technically our Feature Request is still open:
>> Sigfrid made a stronger case in his recent email to TEI-L for
>> registering application/tei+xml than he had previously. Do we want to
>> revisit our decision not to pursue registration?
>> If so, I would suggest that we ask Sigfrid to supply us with the
>> information he thinks we would need to complete the IANA application
>> he seems to be familiar with the process), namely
>> and then we could decide who to authorize as the "Author" of the
>> ---------- Forwarded message ----------
>> Date: Sun, 22 Nov 2009 16:05:26 +0100
>> From: Sigfrid Lundberg <slu at KB.DK>
>> To: TEI-L at listserv.brown.edu
>> Subject: [TEI-L] SV: TEI MIME type
>> The docbook mime type is documented in an internet draft
>> it expired a year or so ago. Don't know why it wasn't renewed.
>> Perhaps the work with XProc and Calabash too much time.
>> In general, an XML application is a document format defined using
>> XML as opposed to applications that are processing XML documents
>> which are xml processors. In my view TEI is an XML application. Mime
>> types for XML applications are described in RFC3023 (http://tools.ietf.org/html/rfc3023
>> ), which clearly states that mime types like
>> is the preferred form. There are also a discussion of this in the
>> recommendation from the W3C "Architecture of the World Wide Web" (http://www.w3.org/TR/webarch/#xml-media-types
>> These practices are now very much integrated in the REST design
>> patterns for web applications. I'd like to take a few examples:
>> One could imagine that someone would like to publish TEI documents
>> using the atom publishing protocol. That is explicitely prohibited
>> for other text/* mime types except text/html. XML documents
>> published using this protocol must be application/*+xml.
>> Consider the situation that we have the same content available
>> through a REST web service, where the representation is chosen
>> through the accept http header, then what if there are more than one
>> XML representation, should TEI then use text/xml and docbook
>> application/docbook+xml? Well, one could live with that, but
>> harvesters that where not prepared for this in advance couldn't.
>> The TEI community is really good at XML, but a registered
>> applicaiton/tei+xml would demonstrate to the world that we regard
>> ourselves as a part of the Wordwide web as well.
>> Fra: TEI (Text Encoding Initiative) public discussion list [TEI-L at listserv.brown.edu
>> ] På vegne af Lou Burnard [lou.burnard at OUCS.OX.AC.UK]
>> Sendt: 21. november 2009 18:34
>> Til: TEI-L at listserv.brown.edu
>> Emne: Re: TEI MIME type
>> Council discussed this recently, and reached the conclusion that there
>> was no advantage (or indeed much sense) in registering a TEI-specific
>> MIME type. It's XML all the way down; not an application as such.
>> Piotr Bański wrote:
>>> Is there one?
>>> Docbook claims to have "application/docbook+xml", but I can't find
>>> it at
>>> So I'm not sure whether the absence of application/tei+xml or
>>> text/tei+xml or whatever ("tei-p5+xml"?) at IANA means that the TEI's
>>> type is not registered or maybe merely not listed there.
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
More information about the tei-council