[tei-council] app-tei-xml: A profile parameter?

Thu Mar 18 08:49:48 EDT 2010

This makes sense to me.

Cheers,
Martin

Sigfrid Lundberg wrote:
> I've read the responses from Brett & Martin & and had a chat with Christian here at the office. An ultrabrief summary of my experiences would could be summarized as follows:
> 
> 1. The content features Martin mentions seems to be as complicated as powerful.
> 2. When trying to read the User Agent Profile from WAP forum I got a password prompt and didn't pursue the task further.
> 3. I agree with Brett that a schema or DTD is more useful than a namespace for a profile parameter.
> 4. My colleague Christian sitting here at KB remarked that if two XML objects have different namespace URIs they should have different mime types.
> 5. Someone, don't remember who, mentioned that the use of profile parameters for xhtml modularization was regarded (by the RFC author) as a temporary work-around.
> 
> In my view, to support both tei p4 and p5 could pose a problem, I propose that we actually define two mime-types application/tei+xml and for legacy data application/teip4+xml
> This means that we can use the profile parameter for other purposes, and service providers can use them both for tei and teip4 data
> 
> Using profiles rather than, say, content features is an advantage, They can be used by a user agent for content negotiation. A clever programmer could expose the range of mediatypes including profiles such that they are available via an OPTIONS HTTP request.
> 
> We should mention the optional profile parameter but I suggest that we leave it's use open for implementers, but that we point out that the profile should not be used for xmlns URIs
> 
> Any other opinions
> 
> Sigge
> 
> 
> 
> 
> ________________________________________
> Fra: Brett Zamir [brettz9 at yahoo.com]
> Sendt: 17. marts 2010 17:37
> Til: Martin Holmes
> Cc: TEI Council; Sigfrid Lundberg; Christian S. Vandel
> Emne: Re: [tei-council] app-tei-xml: A profile parameter?
> 
> On 3/18/2010 12:08 AM, Martin Holmes wrote:
>> 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?
> 
> The RFC says "Though the URI need not be resolved in order to be useful
> as a name, it could be a namespace, schema, or a language
> specification.". I'd favor a schema/DTD rather than a namespace, since
> it is, in practice, more fine-grained. The only problem to me is whether
> the spec should specifically disallow non-conformant versions of TEI
> (i.e., pointing to a DTD or schema which breaks TEI conformance) and
> only allow subsets (as the XHTML spec envisions in speaking of XHTML
> Basic). It'd most likely be hard enough for a vendor to program for P4
> and P5+, let alone impossibly guess at or build in support for more
> specific non-conformant varieties (if people are making them) all under
> the same content type umbrella. P6+ should be easy because I assume
> there will be no reason to move away from <TEI/> as a root tag, nor its
> convenient @version attribute, at least If TEI continues on with the
> same namespace in future versions (as may be possible, I imagine, if
> tags are not redefined so as to be backwards-incompatible).
> 
> Is there a full TEI schema for P5 and P4 online, and if so, does TEI
> want to risk the same problem the W3C faces with DTDs being resolved
> (leading to a kind of attack on the server when applications try to
> resolve the URL)? I doubt the risk would be any greater, since
> content-type sniffers, unlike validators, have no reason to download a
> public URL, but just mentioning it to be safer.
> 
> But to be honest, at least as someone coming from more of a developer
> angle, I think I'd be partial to only allowing TEI P5+, since the web is
> a new field, since P5, in its support for namespaces (and schemas) is
> truly modern, since XSL transforming to P5 is still possible for those
> who wish to deploy P4 to the web, and since P5, in possessing both a
> namespace and version attribute, sets up a nice consistent model for
> future versions. P5 with namespacing also even invites embedding within
> other content, as is especially likely on the web, such that detection
> can only safely be detected via namespace (and having a content-type
> which supports P4 may only encourage people to hang on to P4 longer than
> necessary). For interoperability (and the ability to embed all web TEI),
> I'd really suggest excluding P4 (which has no namespace and is thus
> indistinguishable from other XML which might use the same tag names).
> 
> best wishes,
> Brett
> 
>> 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
>>> .
>>>
> 