Re: [xml-dev] Registration status

On Mon, 29 Oct 2001, David Carlisle wrote:

Sorry for delay (been off line ...)
  
> 
> having to upgrade that installed base is exactly the problem with    
> the xxx+xml proposals. If XML is served as text or application/xml   
....
> 
> But if your mail agent comes across an xxx+xml document and it doesn't 
> know this type, basically it's stumped. It won't even (currently) by   
> default do the "obvious" thing of dropping the xxx+ and trying the more
> general xml mime type.
> 
> you say
> 
> > This of course, is all IMHO, as RFC 3023 explicitly supports you
> > serving all XML as application/xml if you really want to.  But as A.15
> > mentions, there are no apparent downsides from using custom types and
> > several advantages.
> 
....
>
> Incidentally it seems to be widely held belief that text/xml was a
> mistake and that xml ought almost always be in application/xml.  I don't
> really hold that view. For decades TeX users have sent tex markup as
> plain text emails and been more or less happy. I don't see
> (document-oriented) XML as significantly different. If someone sends me
> some email with some mathematics in, and I'm sat at a machine without a
> mathml renderer, I'd much rather just see the mathml markup inline  
> (which can be read, in small doses, honestly:-) than just be offered a
> file/save option on the grounds that the lovingly constructed
> mathematics is just unreadable application specific data.

I've been thinking about this one a bit more, and perhaps a useful
alternative would be to expand upon the XML 'type' information with extra
XML-specific headers ... something like:

Content-type: text/mathml
xml-primary-namespace:  http://www.whatever.org/namespace
xml-secondary-namespace: http://some.other.org/namespace
xml-secondary-namespace: http://and.another.org/namespace

Older MIME-aware applications would just use content-type, and ignore
the rest, while newer 'XML-aware' applications could use the namepace
headers to more finely 'type' the message content, and process it
appropriately.  

Any thoughts?

Ian