[tei-council] app-tei-xml: A profile parameter?
Martin Holmes
mholmes at uvic.ca
Wed Mar 17 12:08:33 EDT 2010
Hi there,
It looks as though the decision to use "profile" back in 2002 was a
provisional one:
The functionality afforded by this parameter can also be achieved
with at least two other more general content description frameworks;
the "Content-features" MIME header described in RFC 2912, and UAPROF
from the WAPforum (see http://www.wapforum.org/what/technical.htm).
At this time, choosing one of these solutions would require excluding
the other, as interoperability between the two has not been defined.
For this reason, it is suggested that this parameter be used until
such time as that issue has been addressed.
<http://www.rfc-editor.org/rfc/rfc3236.txt>
Does anyone know whether the interoperability between RFC 2912 and
UAPROF was ever resolved?
I do see the value in being able to distinguish between P4 and P5 (and
P6, too, eventually). Are we required to specify a range of values ahead
of time for these profiles, or can anything go in these header fields?
Cheers,
Martin
Laurent Romary wrote:
> Hi council,
> Anyone with a strong view on this?
> Laurent
>
> Le 17 mars 10 à 10:28, Sigfrid Lundberg a écrit :
>
>> 'Thanks for comments. I've corrected the source file.
>>
>> I'd like to return to the P5 versus older versions, and TEI Lite
>> issue. I've read the application/xhtml+xml specification (http://www.rfc-editor.org/rfc/rfc3236.txt
>> ), and here they specify a profile parameter which could be used in
>> HTTP content negotiation. For instance a GET request header could
>> include
>>
>> Accept: application/xhtml+xml;
>> profile="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"
>>
>> This would imply that a WWW client only accepts xhtml content as
>> defined by the xhtml-basic10.dtd. TEI modularization is very good,
>> but is there a convention for the naming of profiles? On the other
>> hand, I feel that a profile parameter is very speculative.
>>
>> It seems that it could be meaningful to define the profiles
>>
>> http://www.tei-c.org/Guidelines/P5/
>> http://www.tei-c.org/Guidelines/P4/
>>
>> Any other ideas?
>>
>> Yours
>>
>> Sigfrid
>> ________________________________________
>> Fra: Sigfrid Lundberg
>> Sendt: 16. marts 2010 14:08
>> Til: Brett Zamir
>> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel
>> Emne: SV: SV: [tei-council] app-tei-xml again
>>
>> Here is a version including the revisions I made in response to the
>> comments by Kevin.
>>
>> I'm not mentioning the namespace problem at all. First, this is
>> mostly a problem for people who will use TEI in REST based web
>> services, and they will almost certainly be TEI P5+ Then, this will
>> be a request for comments, so someone knowledgeable could comment
>> if they feel there is need for it ;-)
>>
>> English isn't my native language, so if there's need for correcting
>> my pidgin, please do.
>>
>> Yours
>>
>> Sigfrid
>>
>>
>>
>> ________________________________________
>> Fra: Brett Zamir [brettz9 at yahoo.com]
>> Sendt: 16. marts 2010 13:36
>> Til: Sigfrid Lundberg
>> Cc: Kevin Hawkins; Laurent Romary; Christian S. Vandel
>> Emne: Re: SV: [tei-council] app-tei-xml again
>>
>> I guess the content-type is meant to give it away, but a lot of web
>> processing tools may rely on DOM, XPath, etc. methods which expect to
>> find the TEI namespace... So I wonder whether limiting to P5 and
>> beyond
>> may be better? TEI Lite (P5) will be supported if TEI is supported
>> (managing the full tag set of P5 in at least a generic (text-based)
>> way
>> should not be problematic, e.g., if we made a browser extension to
>> optionally transform a document with the TEI content type but
>> without an
>> attached stylesheet using the default TEI stylesheets behind the scene
>> to render it)...
>>
>> best wishes,
>> Brett
>>
>> On 3/16/2010 8:27 PM, Sigfrid Lundberg wrote:
>>> 1. I agree that there is no reason to exclude P4 and earlier. I've
>>> changed my copy of the document
>>> 2. I've changed the reference to http://www.tei-c.org/Guidelines/
>>> (which reflects 1.)
>>> 3. Added the suffix tei
>>> 4. Changed Tei to TEI
>>>
>>> I don't think there's any problems with TEI lite, they can be
>>> parsed by any TEI aware software. There might be problems mixing
>>> TEI.2 and TEI though.
>>>
>>> Yours
>>>
>>> Sigge
>>> ________________________________________
>>> Fra: Kevin Hawkins [kevin.s.hawkins at ultraslavonic.info]
>>> Sendt: 16. marts 2010 12:41
>>> Til: Laurent Romary
>>> Cc: Sigfrid Lundberg; Christian S. Vandel; Brett Zamir
>>> Emne: Re: [tei-council] app-tei-xml again
>>>
>>> A few notes from a TEI Council member ...
>>>
>>> In the Encoding considerations, change "Tei" --> "TEI"
>>>
>>> The Published specifications says this MIME type is for documents
>>> encoded according to P5 or later. Do we really want to exclude any
>>> P4
>>> documents in XML? What about XML documents in TEI Lite or another
>>> TEI
>>> customization?
>>>
>>> Maybe the Normative References should simply point to
>>> http://www.tei-c.org/Guidelines/ ?
>>>
>>> Under additional information, you might note that some people use the
>>> file extension ".tei". However, you're entirely right that ".xml" is
>>> the most common.
>>>
>>> --Kevin
>>>
>>> On 16/03/2010 11:29, Laurent Romary wrote:
>>>
>>>> OK. The council list does not accept attachments... I had
>>>> forgotten...
>>>> sigh.
>>>> Whoever wants to have a look can ask me directly!
>>>> Laurent
>>>>
>>>>
>>>> Le 16 mars 10 à 11:33, Sigfrid Lundberg a écrit :
>>>>
>>>>
>>>>> Thank Brett,
>>>>>
>>>>> Here is a new version with, I hope, no visible dependencies of the
>>>>> old docbook RFC
>>>>>
>>>>> Cheers
>>>>>
>>>>> Sigfrid
>>>>> ________________________________________
>>>>> Fra: Sigfrid Lundberg
>>>>> Sendt: 16. marts 2010 11:06
>>>>> Til: Laurent Romary; Brett Zamir
>>>>> Cc: TEI Council; Christian S. Vandel
>>>>> Emne: SV: [tei-council] [TEI-L] application/tei+xml
>>>>>
>>>>> Please find attached an early draft to an Internet draft. You can
>>>>> format it as traditional rfc*.txt or to HTML at http://xml.resource.org/
>>>>>
>>>>> I don't know who should be on the list as authors and so forth. I
>>>>> hadn't realised that IETF had such a wonderful infrastructure for
>>>>> writing RFC's and internet drafts
>>>>>
>>>>> The goal is a line here http://www.iana.org/assignments/media-types/application/
>>>>>
>>>>> I suppose we need to fill in the form:on http://www.iana.org/cgi-bin/mediatypes.pl
>>>>> and the draft should be submitted to the IETF
>>>>>
>>>>> Yours
>>>>>
>>>>> Sigfrid
>>>>>
>>>>> ________________________________________
>>>>> Fra: Laurent Romary [laurent.romary at loria.fr]
>>>>> Sendt: 11. marts 2010 19:40
>>>>> Til: Brett Zamir
>>>>> Cc: Sigfrid Lundberg; TEI Council
>>>>> Emne: Re: [tei-council] [TEI-L] application/tei+xml
>>>>>
>>>>> At least stay in the loop with Sigfrid. I let you two do your
>>>>> best to
>>>>> move this foward.
>>>>> Thanks in advance,
>>>>> Laurent
>>>>>
>>>>> 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,
>>>>>> Brett
>>>>>>
>>>>>> 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,
>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> <app-tei-xml.tar.gz>
>>>>>
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>
>
> Laurent Romary
> INRIA & HUB-IDSL
> laurent.romary at inria.fr
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> .
>
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
Half-Baked Software, Inc.
(mholmes at halfbakedsoftware.com)
martin at mholmes.com
More information about the tei-council
mailing list