Simon St.Laurent wrote:
I'd appreciate hearing opinions on this. Apart from a preference for
application/xml over text/xml, the more important issue for me is whether
we should discuss
1) transmitting entities of text/html-xml identified as text/xml
2) transmitting entities of application/html-xml identified as application/xml
I do not think that we need more specialized media types for HTML. text/html,
text/xml, application/xml are good eonugh.
text/xhtml was discussed in this ML, and it was discussed heavily in the
HTML WG. In my understanding, there is a consensus that a new specilized
media type for HTML does not solve any problems. If we need something that
works on
existing browsers, we only have to use text/html. If we need something that
allows addition of other vocabularies (e.g., MathML and RDF), we already have
text/xml and application/xml.
Murray Altheim wrote:
In thinking about this more, I can see the value in defining a new
media type 'text/xhtml' for the family iff we see that all applications
within that space using the same infrastructure and mechanisms for
extensibility, so that any application within that space can predict
how to read what has been extended and the implications of the
extension. We *may* be able to solve that with document profiles.
But if it's still open season within 'text/xhtml' then we've only put
off the problem until later, and also compounded it by meaninglessly
fragmented the 'text/xml' space. If there is a solution for XML it
should be the same as for XHTML, and so my sense is that either the
HTML WG's concept of document profiles is more usable generally in
XML or we're duplicating what must also be done for XML.
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata(_dot_)makoto(_at_)fujixerox(_dot_)co(_dot_)jp