Let's solve the problems that caused us to start this mailing
list in the first place; those problems include the problems
of properly labelling XHTML with various kinds of embedded
tables, math, markup and use of features.
I would like to reiterate these problems, it is the problem of
how a user agent treats an XHTML file.
Basically if I send an XHTML file as text/html, then a browser
will send that file off to its HTML engine, and parse it as an HTML file.
If I send the file as text/xml, then the browser will send it
of to its XML parser, and just create a parse tree.
Now there may be some devices that do not want to accept an
XML file but will be quite happy to accept an XHTML or an
HTML file. Such a device may be a traditional browser
There will also be some devices that are happy to
accept an XML or an XHTML file but not an HTML file, they have
no wish at all to deal with unclosed tags etc.
Both these devivices would like to know what kind of file they
are dealing with before down loading the whole file, hence the
need to identify a file as an XHTML file in some way.
The second problem is as Larry points out is the file with
embedded xml from different namespaces. A browser may be quite
happy to accept an XHTML file and will 'know' how to display basic
XHTML1.0, but will not know how to display mathXML or MusicXML.
Because the Namespaces can be scoped in the document, and don't
have to be in the head of the document, the browser may be well
into rendering the document before it realises that it can't
display the relevant code. It would be nice from the browsers
point of view if it had prior knowledge of the namespaces before
downloading the document, because then it could either
1. Decide to display it as a tree.
2. Send a mesage to the user asking whether it wants the document
down loaded or not.
3. Decide not to down load the document at all.
For this reason there are many who would like to see
a text/xhtml mime type. (This includes my self as I see
that this is the easiest solution to our problem, but then
I am just being selfish).
For the record I think that application/xml.html would be quite
acceptable and presumably (please correct me if I'm wrong) one
could include a whole series of these to define all the namespaces
used in an XHTML document, i.e. application/xml.html,
application/xml.mathml, application/xml.musicml etc.
Others such as Murray (I hope I am not mis-interpreting him!)
have pointed out that they would like a more general solution,
because they feel that an XHTML mime type will keep XHTML off
in it's own landscape and not encourage it to join the more
general XML solution.
Frank
----- Original Message -----
From: Larry Masinter <masinter(_at_)parc(_dot_)xerox(_dot_)com>
To: Rick Jelliffe <ricko(_at_)gate(_dot_)sinica(_dot_)edu(_dot_)tw>
Cc: <ietf-xml-mime(_at_)imc(_dot_)org>
Sent: Monday, May 10, 1999 2:36 PM
Subject: RE: Using CONNEG instead of MIME types for compound types &
references
Let us solve the simple needs of transmitting a simple document
before attempting to get multipart documents correct! Divide and
conquer.
Let's solve the problems that caused us to start this mailing
list in the first place; those problems include the problems
of properly labelling XHTML with various kinds of embedded
tables, math, markup and use of features.
If XML could only allow you to have simple documents without
any of the complexities of compound mixed features, we wouldn't
have started this discussion in the first place, since it would
be fine just to create a new MIME type for each.
Larry