Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Content-Document-Type: was (Re: MIME types vs. DOCTYPE)
 Greetings, Here I am speaking for myself, not the HTML Working Group or CNET: > -----Original Message----- > From: Walter Underwood [mailto:wunder@i...] > Sent: Friday, February 26, 1999 9:42 AM > To: xml-dev@i... > Cc: www-html-editor@w... > Subject: Re: Content-Document-Type: was (Re: MIME types vs. DOCTYPE) <SNIP Content="off-topic"/> > The objection about thin clients or palmtops not wanting to download > large files doesn't really hold water. XML will generally be the > smallest files. Mine are almost always smaller than the corresponding > HTML. Powerpoint, PDF, JPEG -- those are big files. This is simply incorrect. The limited capabilities of thin clients and the expense of transmission of the information require capabilities-based analysis and profiling of documents on a per-client basis. As an example, consider a web-enabled cellphone such as this one: http://www.attws.com/business/pocketnet/index.html. The transmission costs to this device vary greatly worldwide, from ~$1/minute in the US to ~$22/min in Nairobi (actually you can only get basic cell phone via satellite in Nairobi, but let's pretend.) If I send a 1/2 megabyte XHTML file to this device, including its 100K CSS stylesheet, the user is entirely justified in bringing legal action against me. The page would cost many tens or hundreds of dollars to send, and of course could not be displayed. In fact the client phone would necessarily display an HTTP error message (or its equivalent) on the tiny screen. Not to mention the costs of transmitting the inevitable ~12k banner ad, which again cannot be displayed. (Information may want to be free but information providers want to get paid.) At this point in time, no method other than MIME types exists for informing the client of the type of content arriving, without first downloading the entire file and then checking it, an obvious absurdity. Doctypes, FPIs, etc. have all be suggested, but none of these solutions provides the necessary level of transaction control required to identify the content prior to content reception. Given the massive costs involved, the client must always be allowed to reject content prior to downloading the entire file. > Adding an XML-specific HTTP header line makes HTTP 1.1 more complex > (shudder), and imposes an extra coding and testing burden on HTTP > implementations. Also, it does nothing for XHTML over other > transports, > like SMTP or FTP. It is also introducing a new set of dependencies for all XML documents. Not feasible. > Essentially, this is document information, not protocol information. > It belongs in the document. To describe the document out-of-line, > use RDF, not HTTP headers. Thin clients will almost necessarily reject all RDF documents (and most XML documents in general). RDF is complex and experimental; I am unconvinced that a cell phone should have to deal with it. > Pragmatically, HTTP Content-type isn't even reliable. Somebody will > decide that Excel and XML are the same thing, and start serving > spreadsheets as text/xml. Cell phones have to deal with that world, > and adding things to the HTTP spec doesn't fix ignorant sysadmins. True; unfortunate; costly for the victims; possibly legally actionable. > XHTML Spec comment: the spec doesn't mention application/xml. > It should. > If application/xml is never appropriate for XHTML (say, the UTF-16 > encoding is forbidden), then say so. The XHTML spec is very clear on this, explicitly stating the MIME types that can be used. No other MIME types are *ever* appropriate. With MIME types being used for document type identification, sending a document with the wrong MIME type guarantees an error. > > XHTML Spec comment: Are the Strict, Transitional, and Frameset DTDs > subsets or extensions? Or neither? Is one a subset of another? These > intentions should be spelled out in the spec so that future versions > won't break them. > The 3 XHTML DTDs are neither subsets or extensions in a literal sense. They correspond as closely as possible to the HTML 4.0 DTDs of the same names. While to some extent the 'strict' DTD is a subset of the other two, it also uses different content models for elements with the same name. Once could not, for practical purposes, use it as an external subset and include the frameset DTD as an internal DTD subset without conflict between their content models. I will not attempt to justify the division of HTML into these 3 groupings - this was decided by the HTML 4.0 committee and is loosely justified by the HTML 4.0 specification. Current attempts are designed to follow this existing prior art to the greatest extent possible. Regards, D- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
