[tei-council] [TEI-L] application/tei+xml

[Laurent Romary]

Thanks a lot!
Laurent

Le 11 mars 10 à 10:53, Sigfrid Lundberg a écrit :

>
> Hi Laurent,
>
> Yeah, since I'm one of those who raised the issue I'll have a look  
> at it next week
>
> Sigge
>
> ________________________________________
> Fra: Laurent Romary [laurent.romary at loria.fr]
> Sendt: 11. marts 2010 08:19
> Til: Sigfrid Lundberg; Brett Zamir
> Cc: TEI Council
> Emne: Fwd: [tei-council] [TEI-L] application/tei+xml
>
> 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,
> Laurent
>
>>
>> ---------- 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?
>>
>> Brett
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>