Re: [xml-dev] Text/xml with omitted charset parameter

[Bjoern Hoehrmann <derhoermi@gmx.net>]

* John Cowan wrote:
>Bjoern Hoehrmann scripsit:
>
>> We cannot learn, we can just be wise and use always application/* for
>> I18N reasons until MIME is dead. Tim Berners-Lee recently suggested that
>> URIs should be used for Content-Types. 
>
>Actually, I've been pushing that idea for some time, and in fact such
>URIs already exist.  The URI corresponding to media-type xxx/yyy
>is simply http://www.isi.edu/in-notes/iana/assignments/media-types/xxx/yyy
>(there really is a file there!).
>
>And it would be trivial to map the Content-Type properties to
>the query part of the URI.

Yeah, we could even define HTML maps to text/html or create some cool
URN scheme like urn:iana:types:text:html to map to text/html, but this
does not help. Content-Type header fields are limited to us-ascii, as
are URIs, changing syntax this way, does not even improve this i18n
problem. We need a better framework for content profile information. 

This is vital for XML, to turn the discussion ontopic. Currently we can
say "this is XML" and "i am able to process XML". This is ok if the
sender only has a single XML application available and the recipient
only accepts a single XML application. On the World Wide Web this is
insufficient. We have senders with various XML applications and
recipients that support various XML applications. A recipient may any
time say "I support SVG". That's cool, but this doesn't say what the
recipient means by "support". Is it able to render the SVG image to a
user? Will it render the SVG image to some bitmap graphic? Does it
support interaction or should I (as sender) better send a SVG image
that is optimized for non-interactive users? Will the recipient just
collect some meta data? Does it support SVG 1.0 or SVG 2.0? I also have
a XHTML document available. Does my recipient like XHTML better than
SVG? What about context, i.e. should the resource by rendered to a user
as part of a larger document? In this case it might be better to send
SVG in place of XHTML. However, the XHTML documents contains MathML and
SMIL. Will it work for you? I have the math parts also available as PNG
image, should I better send a XHTML document that links some PNG image
in order to ensure the user gets the math right? Recipient wants to get
a sitemap, XHTML or RSS? What XHTML version is supported, what modules,
what style sheet should I supply? Billions of szenarios. Saying "this is
XML" and "i am able to process XML" is not sufficient. CC/PP may solve
some issues but it misses it's content profile framework pendant. If
there is such framework, identification matters, but I am not aware of
any. MIME and HTTP Content-Negotiation do a bad job in this regard. The
MIME Content-Type mechanism is not extensible enough, something like
application/xhtml11+smil20+ecmascript+png+rdf+xml works aswell as the
text/* vs. application/* thing, it doesn't (even though, for different
reasons).

wishes.
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/