[tei-council] [TEI-L] application/tei+xml
laurent.romary at loria.fr
Thu Mar 11 13:40:52 EST 2010
At least stay in the loop with Sigfrid. I let you two do your best to
move this foward.
Thanks in advance,
Le 11 mars 10 à 18:56, Brett Zamir a écrit :
> Hello Laurent,
> I'd be happy to try to spell out the use case with which I am best
> familiar, but I'm quite swamped at the moment to do much else
> (looking for work actually).
> best wishes,
> On 3/11/2010 3:19 PM, Laurent Romary wrote:
>> Dear Sigfrid and Brett,
>> Following a message from Brett on the TEI-L, I would like to ask
>> you if you could give a hand in implementing the already made
>> decision from the council (Cf. http://lists.village.virginia.edu/pipermail/tei-council/2009/011465.html)
>> to proceed with an application/tei+XML MIME type. One would have
>> to fill out a IANA application, and I could well be the formal
>> submitter as council chair.
>> Would you have some time to dedicate to this?
>> Thanks in advance,
>>> ---------- Forwarded message ----------
>>> Date: Wed, 10 Mar 2010 12:36:51 +0800
>>> From: Brett Zamir <brettz9 at YAHOO.COM>
>>> To: TEI-L at listserv.brown.edu
>>> Subject: [TEI-L] application/tei+xml redux
>>> To resurrect an old (and I know, already settled) question, I
>>> think I may have found a good use for
>>> application/tei+xml after all.
>>> I am currently working on proposing/developing a modification of
>>> METS which can be used not only to download
>>> a set of TEI files in the browser and with stylesheets (as well as
>>> XQuery like mentioned in my other recent
>>> post, etc.), but also potentially supply XSLT files without TEI or
>>> XML, such as TEI's own stylesheets, and
>>> allow them to register themselves as content handlers for
>>> application/tei+xml content encountered on the web
>>> and/or as namespace handlers which could operate within any
>>> documents containing the TEI namespace (such as
>>> embedded within XHTML).
>>> This might even operate at an individual tag level (e.g., to
>>> replace native XHTML buttons with one's own
>>> HTML5 "canvas"-drawn element or, in the case of TEI, to override
>>> the default styling provided by Sebastian's
>>> stylesheets for certain tags).
>>> Thus, TEI files in the browser could be shown (by default) in one
>>> standard format across web pages, at least
>>> if they were not pre-styled by the author, with the major bonus of
>>> the user not needing to re-download the
>>> same standard stylesheets, especially when visiting a new TEI-
>>> hosting site, after they had obtained the
>>> stylesheets just once from any page as long as it registered
>>> itself as a TEI content handler (though since
>>> multiple content handlers could be registered, TEI's own
>>> stylesheets would not need to be the only choice
>>> out there when viewing TEI and users could switch between handlers
>>> for specific pages). The overhead of
>>> client-side XSL would be obviated greatly by not having to
>>> transfer the often large stylesheet files across
>>> the web upon each new site visit; the only extra overhead compared
>>> to regular XHTML would be the internal
>>> conversion made by the browser (which is very little in comparison
>>> to network transmission).
>>> The manifest file within the file package containing the
>>> stylesheets could also indicate an update URL which
>>> could be checked for new updates to the stylesheets.
>>> I think this could remove the primary barrier to serving TEI
>>> directly on the web and having it be directly
>>> viewed without long delays.
>>> Besides TEI, other experimental or alternative formats like
>>> Markdown, ODF, localized XHTML (e.g.,
>>> http://bahai-library.com/zamir/chintest9.xml ) could become
>>> possible and practical if applied in other
>>> browsers and by default.
>>> What do people think of this?
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
More information about the tei-council