Re: text/html for xml extensions of XHTML

At 11:10 AM 2001-05-03 -0400, William F. Hammond wrote:
>David Carlisle <davidc@nag.co.uk> writes:
>
>> I think it would be useful for mozilla/netscape to bail out of HTML
>> parsing if it sees an xml declaration at the start of the file, but it
>> certainly isn't broken if it does not do that.
>
>From RFC 2854, 'The media type "text/html"':
>
>-----
>
>   This document summarizes the history of HTML development, and
>   defines the "text/html" MIME type by pointing to the relevant W3C
>   recommendations;
>
>. . .
>
>   Published specification:             ...  In addition, [XHTML1]
>   defines a profile of use of XHTML which is compatible with HTML
>   4.01 and which may also be labeled as text/html.
>
>-----
>
>An XML declaration has a parameter "encoding", and a text/html http
>object, if not 7 bit ascii, is served with a charset value, as part of
>its content type descriptor.  (And, of course, there may also be a
>content transfer encoding at the http level.)
>
>I wonder if concern over the task of the proposed pre-parse fast light
>weight analysis of the top of the http body involves charset issues.
>
>Along with that I wonder if it might be useful to have an elaboration
>in the definition of text/html of the relationship between
>http/content-type/charset and xml/encoding when the XML form of HTML
>is served as "text/html".
>

AG::

Yes, it would be useful to have a blow by blow explanation.

No, the documentation for text/html is not the place to address this.

This is a matter of compatibilty between two IETF documents: HTTP and MIME.

It affects all XML documents carried in HTTP.

It is the sort of thing that has historically be discussed on ietf-types list.

Once the answer is known, the question of where-all to document and point to
the answer should be raised.

That addresses your specific point raised in this post.

On the broader issue, it is still an HTTP/MIME/packaging issue.

If people want not to be at the mercy of their server adminstrator as to the
[HTTP header] metadata that get ingested by their customers' User Agent, they
need to look at MIME or other packaging techniques to send a manifest up front
that can have all the logical complexity you want, with a search list of
parse-as directives governing the companion [de novo body] bundled payload.

The question is at what point is the world at large ready to get off RFC
822 as
the means of providing metadata wrappings?

Or what QA practice with regard to the servers will begin to get the metadata
served right?  The server could afford the cycles to restart another parser if
confirming type metadata on upload.  If they would but do it.

Al

>                                    -- Bill
>

Received on Thursday, 3 May 2001 12:45:31 UTC