Subject: Re: [xml-dev] Text/xml with omitted charset parameter
From: MURATA Makoto <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Sun, 28 Oct 2001 00:32:09 +0900 (JST)
List-Id: <ietf-xml-mime.imc.org>

From: Bjoern Hoehrmann <[email-masked]>
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Date: Fri, 26 Oct 2001 04:42:01 +0200

> 
> * Michael Brennan wrote:
> >Mentioning UTF-16 in this example is not absurd at all.
> 
> It is at least misleading, since it doesn't say,
> this case is invalid and won't work. In fact, it
> implies the contrary to me.

When we create a new RFC, we should rename the subsection.   

8.5 INCONSISTENT EXAMPLE: Text/xml with Omitted Charset

is better than

8.5 Text/xml with Omitted Charset

Cheers,

Makoto

From: Bjoern Hoehrmann <[email-masked]>
To: "Henrik Frystyk Nielsen" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Mark Nottingham" <[email-masked]>
Subject: Re: Question on status of '+xml' notation
Date: Tue, 30 Oct 2001 05:37:57 +0100
Organization: none
Sender: [email-masked]

* Henrik Frystyk Nielsen wrote:
>Hi folks,
>
>The W3C XML Protocol WG is wondering what the status of the "+xml"
>suffix given that various W3C recommendations that have come out after
>the RFC rolled out seem to make any of the three choices:
>
>	* don't use "+xml"
>	* use "+xml"
>	* don't say anything about MIME
> 
>We would very much appreciate input on what the deployment status is of
>RFC 3023. Note that we are not asking the status of the document itself
>but rather the adoption rate in specs and apps.

SVG and XHTML have adopted the +xml suffix, the application/xhtml+xml
MIME Type registration is in Last Call and the SVG 1.0 recommendation
defines image/svg+xml, registration has not started yet, but it's very
unlikely that a different MIME Type will be registered. I am not aware
of any post-RFC 3023 MIME Type registration, where the +xml suffix has
not been used, at least not in the IETF tree.

HTH,
-- 
Björn Höhrmann { mailto:[email-masked] } 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/

Date: Mon, 29 Oct 2001 19:23:47 -0800 (PST)
From: [email-masked]
Subject: Re: Question on status of '+xml' notation
To: Henrik Frystyk Nielsen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Mark Nottingham <[email-masked]>
Sender: [email-masked]

> The W3C XML Protocol WG is wondering what the status of the "+xml"
> suffix given that various W3C recommendations that have come out after
> the RFC rolled out seem to make any of the three choices:

> 	* don't use "+xml"
> 	* use "+xml"
> 	* don't say anything about MIME
 
> We would very much appreciate input on what the deployment status is of
> RFC 3023. Note that we are not asking the status of the document itself
> but rather the adoption rate in specs and apps.

Speaking as media types reviewer, I interpret RFC 3023 as saying that XML-based
media type registrations should follow the +xml convention whenever possible.
I've therefore pushed back on media type registration requests where I was able
to figure out that the underlying format is XML-based (this isn't always
obvious), and in most cases the registrations were revised accordingly. I'm
also starting to see registrations that have +xml in them from the outset.

				Ned

Subject: Re: [xml-dev] Re: determining ID-ness in XML
To: [email-masked]
Date: Mon, 29 Oct 2001 21:14:06 -0500 (EST)
CC: Tim Bray <[email-masked]>, [email-masked], [email-masked]
From: John Cowan <[email-masked]>
Sender: [email-masked]

Daniel Veillard scripsit:

>   I would be tempted to say that xml:id being an ID, it's an
> ID duplicate and hence the document is invalid. No such document
> should exist at the moment since xml: is reserved ...

I agree except for the word "invalid"; it should be merely
xml:id-unconforming.

-- 
John Cowan           http://www.ccil.org/~cowan              [email-masked]
Please leave your values        |       Check your assumptions.  In fact,
   at the front desk.           |          check your assumptions at the door.
     --sign in Paris hotel      |            --Miles Vorkosigan

Date: Mon, 29 Oct 2001 15:12:07 -0800 (PST)
From: [email-masked]
Subject: Re: [xml-dev] Registration status
To: David Carlisle <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > Now, all we need to do is upgrade the entire installed
> > based of Internet-connected machines that understand MIME, and I'll
> > agree that a MIME registration for backward compatibility is no longer
> > necessary.

> having to upgrade that installed base is exactly the problem with
> the xxx+xml proposals. If XML is served as text or application/xml
> then you do get a reasonable default behaviour (for example your mail
> agent might ship all such files to internet explorer for display.
> IE has a reasonable default presentation of XML and its default
> stylesheet could easily include special cases for things like svg and
> xhtml (and until then the document can specify a specific stylesheet).

That may be your opinion. My experience has been otherwise.

> 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.

Hardly. Adding an entry for a new type is one of the things most agents allow,
and generally handle pretty well.

And some agents even support wildcarding that will allow */*+xml to be
redirected. (I'm actuaally not in favor of this. I'd rather have a new type
bring up a dialogue that lets me pick the app I want to use.)

> > 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.

> but A.15 (which I have re-read) is about the benefits of using a +xml
> suffix as opposed to not. I agree, if there is to be a mime type for
> mathml then it may as well be text/mathml+xml rather than just text/mathml.
> I don't think there is any argument with that. But until mime agents are
> upgraded to _automatically_ fall back to text/xml if they receive a
> text/mathml+xml document and they don't know that mime type, then
> anyone serving mathml files would be well advised to serve them as
> text/xml as they will have a much wider chance of being processed.

> 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.

Speaking as someone who spent years and years doing technical support for
a math department, I have to say that your experience with users is
the exact opposite of mine in all of this.

				Ned

From: "Bullard, Claude L (Len)" <[email-masked]>
To: [email-masked], "Champion, Mike" <[email-masked]>
Cc: Tim Bray <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [xml-dev] Re: determining ID-ness in XML
Date: Mon, 29 Oct 2001 17:04:11 -0600
Sender: [email-masked]

Remember, you are stuffing processor requirements in 
there (why people dislike PSVI).  It is possible that 
some boundary exists between well-formed and validated 
documents, and so far, no one seems to know just where 
that is, yet XML was proposed, designed and sold on the 
notion someone would know.  What we got instead was a 
step by step inching into a system in which semantics 
are being inserted via magic strings that are eroding 
the boundary between processor and content.

No agreement without a clear and clean requirement.
All you have said is a gap exists.  Examples 
have been provided to show no gap exists; you don't 
like the solutions.  That puts the burden of specing a 
requirement in the proposer's camp.

Nyet.  Not without a clear consensus that 
such a thing is really required and that existing 
solutions are not adequate.  Start there; not with 
the end game.

len

-----Original Message-----
From: Daniel Veillard [mailto:[email-masked]]

  Hum, not sure I catch your point. Mine is that WG are busy, and 
if getting a NOTE in /TR is relatively easy, getting a REC needs 
a Working Group scheduled to do it. Doing XML Id would be similar to
do XML Base (retroffitting a change using the gap left in the 1.0
infrastructure) and as much as I would like to see people agreeing
quickly on it and getting it out in a couple of month, I know from
experience it is not possible (again I would love to be proven wrong !)

From: "Bullard, Claude L (Len)" <[email-masked]>
To: "Champion, Mike" <[email-masked]>, [email-masked], Tim Bray <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [xml-dev] Re: determining ID-ness in XML
Date: Mon, 29 Oct 2001 16:45:54 -0600
Sender: [email-masked]

That's a crock, Mike.

len

-----Original Message-----
From: Champion, Mike [mailto:[email-masked]]

Hmmm ..... check out
http://www.nytimes.com/2001/10/29/technology/29WEB.html

"The [MSN vs Opera/Mozilla/etc.] imbroglio was another example of how the
Web is really regulated. It is not a matter of enforcement agencies in
Washington, politicians or lobbyists. Instead, the Internet cops on the
block are mainly a band of elite - and vigilant - software experts who keep
things honest because they have the technical and moral authority. Their
views cannot be ignored."

What's sauce for Microsoft is sauce for the W3C, no? 

From: "Champion, Mike" <[email-masked]>
To: [email-masked], Tim Bray <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [xml-dev] Re: determining ID-ness in XML
Date: Mon, 29 Oct 2001 17:29:48 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Daniel Veillard [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 4:57 PM
> To: Tim Bray
> Cc: [email-masked]; [email-masked]
> Subject: Re: [xml-dev] Re: determining ID-ness in XML
> > Procedurally?  A new W3C note leading to a tiny 2-page REC,
> > I'd say.  Easier than re-opening either the XML or Namespace
> > RECs. 
> 
>   Agreed, though there isn't that many WG who can handle this
> at the moment, I see only Core, and one may need to apply serious
> pressure to get more work added to an existing WG. But who knows ...

Hmmm ..... check out
http://www.nytimes.com/2001/10/29/technology/29WEB.html

"The [MSN vs Opera/Mozilla/etc.] imbroglio was another example of how the
Web is really regulated. It is not a matter of enforcement agencies in
Washington, politicians or lobbyists. Instead, the Internet cops on the
block are mainly a band of elite - and vigilant - software experts who keep
things honest because they have the technical and moral authority. Their
views cannot be ignored."

What's sauce for Microsoft is sauce for the W3C, no? 

Date: Mon, 29 Oct 2001 11:42:18 -0800
From: David Brownell <[email-masked]>
Subject: Re: [xml-dev] Re: determining ID-ness in XML
To: Tom Bradford <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> >> 1.  use the internal subset to declare IDs.
> 
> Wouldn't this have even deeper implications? 

It shouldn't, for conforming implementations of XML.

>     By this I mean that a 
> validating parser won't validate a document that has no DOCTYPE 
> references (treats it simply as well-formed), but *will* try to validate 
> a document in an all-or-nothing fashion if there is.

The XML spec doesn't say any such thing.  In fact it's quite clearly
possible to validate documents with no <!DOCTYPE ...> declaration
(and get lots of errors).  The conformance section of the XML spec
describes validating parsers, and non-validating parsers, but not this
"sometimes validates" behavior you describe.

You may be confusing the XML standard with what Microsoft does
in some of their implementations.

- Dave

p.s. why is the IETF mime list CC'd?

From: "Champion, Mike" <[email-masked]>
To: "Fred L. Drake, Jr." <[email-masked]>, "Champion, Mike" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [xml-dev] Re: determining ID-ness in XML
Date: Mon, 29 Oct 2001 14:40:48 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Fred L. Drake, Jr. [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 2:27 PM

>  > Logically xml:id should "win", but for backwards 
> compatibility, I'd say that the application ID should "win". 
> 
>   Which is a good reaason to decree it to be an error -- ambiguity is
> our enemy.

Yes: A much better idea than setting rules to pick the winner!

Date: Mon, 29 Oct 2001 10:53:41 -0800
To: [email-masked], [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: determining ID-ness in XML
Sender: [email-masked]

[Trying to keep this one on both xml-dev & ietf-xml-mime]

At 08:40 AM 29/10/01 -0600, Paul Grosso wrote:
>Here are some options (all discussed before):
>1.  use the internal subset to declare IDs

#1 is minimal-impact.  Can it be sold?  I.e., if you
want the "name" attr to be an ID, then you need the following
at the top of the file with a line for each element type
that "name" can appear on:

<!DOCTYPE rootType [
 <!ATTLIST element1 name ID #IMPLIED>
 <!ATTLIST element2 name ID #IMPLIED>
 ... etc...
]>

I'm not sure it's going to be easy to get the community to
buy into this.

>2.  use a PI to declare IDs

Yecch.  Barf.  Blecch.  Feh.  Oh, this is supposed to
be a technical discussion.

>3.  put an xml:id attribute into the xml namespace
>Are there others?  What are the pros and cons?

The advantage of xml:id is that the "xml" namespace 
doesn't need to be declared per the namespace rec.

You could have another namespace declared like so

<rootEl xmlns:xmlid="http://www.w3.org/2001/xmlid/">
 <foo xmlid:a="label1">
 <bar xmlid:b="label2">
</rootEl>

where the semantic is that no two attributes in this
namespace can have the same value in the same doc, 
and you *might* even be able to get away without requiring
a namespace declaration, since those beginning in "xml" are
reserved per the namespace spec, presumably for exactly
this kind of thing.

Note that this is not mutually exclusive with having xml:id.  

My own opinion is that this is unnecessary complexity - just
use xml:id... the advantage of having a new namespace, that
you get to choose your own names for IDs, is kind of 
obviated by the fact that attribute prefixes don't default
so you're always going to have that ugly xmlid: in front, so
why not just bite the bullet and use xml:id?

And as I said, I think it's still not too late to take this
kind of a step.

>In short, what's the right answer?

Procedurally?  A new W3C note leading to a tiny 2-page REC,
I'd say.  Easier than re-opening either the XML or Namespace
RECs. 

The namespace approach(es) have the huge advantage of making
an important semantic aspect of XML documents self-
documenting.  In fact, on the Web, I might argue that the
lack of a clear self-documenting way of establishing the
semantics of '#whatever' in a URI reference is a nearly
fatal architectural flaw.

Hm.... the one problem is that if you're dealing with XHTML
or SVG, which already *have* ID elements defined normatively
as part of the language, you have to say what happens when
there's a conflict, e.g. suppose you have

<html:div id="p3"> ... </div>
<html:div xml:id="p3"> ... </div>

Is this an error, or does the built-in id "win", or do we
leave it up to language designers to define how to coexist
with xml:id?  -Tim

Content-Class: urn:content-classes:message
Subject: Question on status of '+xml' notation
Date: Mon, 29 Oct 2001 09:53:38 -0800
From: "Henrik Frystyk Nielsen" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Mark Nottingham" <[email-masked]>
Sender: [email-masked]

Hi folks,

The W3C XML Protocol WG is wondering what the status of the "+xml"
suffix given that various W3C recommendations that have come out after
the RFC rolled out seem to make any of the three choices:

	* don't use "+xml"
	* use "+xml"
	* don't say anything about MIME
 
We would very much appreciate input on what the deployment status is of
RFC 3023. Note that we are not asking the status of the document itself
but rather the adoption rate in specs and apps.

Thanks for any input!
 
Henrik

Reply-To: "Jens-H. Niggemeyer" <[email-masked]>
From: [email-masked] (Jens-H. Niggemeyer)
To: <[email-masked]>
Subject: Fw: [email-masked]
Date: Mon, 29 Oct 2001 16:45:02 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01C16099.0E46FA80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe
----- Original Message -----=20
From: Jens-H. Niggemeyer=20
To: [email-masked]=20
Sent: Monday, October 29, 2001 10:16 AM
Subject: [email-masked]

unsubscribe [email-masked]

------=_NextPart_000_0077_01C16099.0E46FA80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT face=3DArial size=3D2>unsubscribe</FONT></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] href=3D"mailto:[email-masked]">Jens-H.=20
Niggemeyer</A> </DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
<DIV><B>Sent:</B> Monday, October 29, 2001 10:16 AM</DIV>
<DIV><B>Subject:</B> <A=20
href=3D"mailto:[email-masked]">[email-masked]</A></DIV></DI=
V>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>unsubscribe <FONT size=3D1><A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FONT></F=
ONT></DIV></BODY></HTML>

------=_NextPart_000_0077_01C16099.0E46FA80--

Date: Mon, 29 Oct 2001 08:40:15 -0600
To: [email-masked]
From: Paul Grosso <[email-masked]>
Subject: determining ID-ness in XML
Sender: [email-masked]

At 20:49 2001 10 28 -0800, Tim Bray wrote:
>The problem is that at the moment, given some arbitrary XML,
>there is *no* good way to determine what's an ID without recourse 
>to some external resource like a DTD or schema, and that, to use 
>a technical term, sucks.
>
> I at 
>least will be arguing in favor of this whenever I get a chance.

I'm interested in this problem too.

Here are some options (all discussed before):

1.  use the internal subset to declare IDs
2.  use a PI to declare IDs
3.  put an xml:id attribute into the xml namespace

Are there others?  What are the pros and cons?

In short, what's the right answer?

paul

Date: Mon, 29 Oct 2001 09:44:40 GMT
From: David Carlisle <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

> Now, all we need to do is upgrade the entire installed
> based of Internet-connected machines that understand MIME, and I'll
> agree that a MIME registration for backward compatibility is no longer
> necessary.

having to upgrade that installed base is exactly the problem with
the xxx+xml proposals. If XML is served as text or application/xml
then you do get a reasonable default behaviour (for example your mail
agent might ship all such files to internet explorer for display.
IE has a reasonable default presentation of XML and its default
stylesheet could easily include special cases for things like svg and
xhtml (and until then the document can specify a specific stylesheet).

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.

but A.15 (which I have re-read) is about the benefits of using a +xml
suffix as opposed to not. I agree, if there is to be a mime type for
mathml then it may as well be text/mathml+xml rather than just text/mathml.
I don't think there is any argument with that. But until mime agents are
upgraded to _automatically_ fall back to text/xml if they receive a
text/mathml+xml document and they don't know that mime type, then
anyone serving mathml files would be well advised to serve them as
text/xml as they will have a much wider chance of being processed.

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.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Reply-To: "Jens-H. Niggemeyer" <[email-masked]>
From: [email-masked] (Jens-H. Niggemeyer)
To: <[email-masked]>
Subject: [email-masked]
Date: Mon, 29 Oct 2001 10:16:04 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C16062.B74505A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe [email-masked]

------=_NextPart_000_0013_01C16062.B74505A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT face=3DArial size=3D2>unsubscribe <FONT=20
size=3D1>[email-masked]</FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0013_01C16062.B74505A0--

Date: Sun, 28 Oct 2001 20:49:36 -0800
To: [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Preparing for XPointer
Sender: [email-masked]

At 03:49 AM 29/10/01 +0100, Chris Lilley wrote:
>> During that thought experiment, it occurred to me that we should
>> be watching +xml registrations to ensure that, where possible,
>> "#foo" syntax is reserved for identifying fragments labelled with
>> an ID (or http://www.w3.org/2001/XMLSchema#id) type attribute of
>> value "foo".
>
>Yes.
>
>And other schems for example #xpty(foo) or #xpath(foo) or #bar(foo)
>would be clearly distinguishable.
> 
>> This would ensure that XPointer could be be retrofitted into
>> 3023 later and apply to all */xml and */*+xml types.

Erk.  Danger, Will Robinson.  This is in danger of tripping over
what is maybe the #1 gaping architectural hole as regards XML & the
Web.  The problem is that at the moment, given some arbitrary XML,
there is *no* good way to determine what's an ID without recourse 
to some external resource like a DTD or schema, and that, to use 
a technical term, sucks.

One could dismiss the problem and say "well, XHTML defines what
an ID is, so does SVG, and so on, and so there's no problem in 
the general case because there's no general case".  But I'd like 
to have foo#bar be meaningful even if "foo" is served up as 
application/xml.

Since fortunately there isn't much in the way of deployment of
hyperlinks trying to point into XML documents, it is NOT TOO LATE
to bite the bullet and do something radical to fix this.  I at 
least will be arguing in favor of this whenever I get a chance.
Which if successful would probably have an impact on one or more 
media-type RFCs.  -Tim

Date: Mon, 29 Oct 2001 03:49:42 +0100
From: Chris Lilley <[email-masked]>
To: Mark Baker <[email-masked]>
CC: [email-masked]
Subject: Re: Preparing for XPointer
Sender: [email-masked]

Mark Baker wrote:
> 
> Hi all,
> 
> In working on the registration of application/xhtml+xml, one of the
> issues was how to best handle a possible transition to XPointer.
> 
> During that thought experiment, it occurred to me that we should
> be watching +xml registrations to ensure that, where possible,
> "#foo" syntax is reserved for identifying fragments labelled with
> an ID (or http://www.w3.org/2001/XMLSchema#id) type attribute of
> value "foo".

Yes.

And other schems for example #xpty(foo) or #xpath(foo) or #bar(foo)
would be clearly distinguishable.

> 
> This would ensure that XPointer could be be retrofitted into
> 3023 later and apply to all */xml and */*+xml types.

Yes.

-- 
Chris

From: Bjoern Hoehrmann <[email-masked]>
To: Chris Lilley <[email-masked]>
Cc: [email-masked]
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Date: Mon, 29 Oct 2001 01:49:30 +0100
Organization: none
Sender: [email-masked]

* Chris Lilley wrote:
>Thus, all xml content should be served as applicvation/xml and use of
>text/xml should be deprecated.

Why didn't the RFC say so?
-- 
Björn Höhrmann { mailto:[email-masked] } 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/

From: "Dan Kohn" <[email-masked]>
To: "'David Carlisle'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [xml-dev] Registration status
Date: Sun, 28 Oct 2001 16:42:36 -0800
Importance: Normal
Sender: [email-masked]

In theory, I agree that namespaces are a better dispatch mechanism than
MIME types.  Now, all we need to do is upgrade the entire installed
based of Internet-connected machines that understand MIME, and I'll
agree that a MIME registration for backward compatibility is no longer
necessary.

In theory, there is no difference between theory and practice. But, in
practice, there is.
- Jan L. A. van de Snepscheut 

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: David Carlisle [mailto:[email-masked]] 
Sent: Sunday, October 28, 2001 16:36
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [xml-dev] Registration status

> David, as the co-author of RFC 3023, I would appreciate if you would
> reread it.  We covered these issues in an extensive mailing list
> archive, but tried to distill them into appendix A.
:-) Yes I will (but I think I'll sleep first, getting late..)

> Now, I agree that compound types cannot be handled ideally by MIME,
but
> the MIME concept of dispatching to the correct application is still
> useful.

yes but as I mentioned my comments were mainly addressed at mathml+xml 
(as that was the question that started the thread) given that most
mathml lives inside something else, I do now wonder  whether it's useful
to have any mathml-specific mime type.
The email agent dipatching example does suggest (as someone else
commented) that having xxx+xml based on the document element is useful.
ie xhtml+xml is fine. But that an xhtml+mathml+svg+... document should
just be xhtml+xml rather than worrying too much about compound
documents. If that's the road we take then mathml+xml is a logical thing
to have for those (relatively few) standalone mathml documents, and it
probably should be registered anyway, as having examples based on
unregistered types is just confusing in the long run.

Somehow it just feels wrong. I think it's the idea of registration,
given that XML in general and namespaces in particular are expressly
designed to allow you to design your own languages without needing to
refer to any central authority, the idea of having to register
things with anyone (even the good guys in the ietf:-) seems very
unnatural. Of course this is really a matter of perception rather than
substance. Whilst I can invent a new language in my own namespace 
and not tell anyone about it, there's not a lot of point unless I only
talk to myself..

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Date: Mon, 29 Oct 2001 00:36:16 GMT
From: David Carlisle <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

> David, as the co-author of RFC 3023, I would appreciate if you would
> reread it.  We covered these issues in an extensive mailing list
> archive, but tried to distill them into appendix A.
:-) Yes I will (but I think I'll sleep first, getting late..)

> Now, I agree that compound types cannot be handled ideally by MIME, but
> the MIME concept of dispatching to the correct application is still
> useful.

yes but as I mentioned my comments were mainly addressed at mathml+xml 
(as that was the question that started the thread) given that most
mathml lives inside something else, I do now wonder  whether it's useful
to have any mathml-specific mime type.
The email agent dipatching example does suggest (as someone else
commented) that having xxx+xml based on the document element is useful.
ie xhtml+xml is fine. But that an xhtml+mathml+svg+... document should
just be xhtml+xml rather than worrying too much about compound
documents. If that's the road we take then mathml+xml is a logical thing
to have for those (relatively few) standalone mathml documents, and it
probably should be registered anyway, as having examples based on
unregistered types is just confusing in the long run.

Somehow it just feels wrong. I think it's the idea of registration,
given that XML in general and namespaces in particular are expressly
designed to allow you to design your own languages without needing to
refer to any central authority, the idea of having to register
things with anyone (even the good guys in the ietf:-) seems very
unnatural. Of course this is really a matter of perception rather than
substance. Whilst I can invent a new language in my own namespace 
and not tell anyone about it, there's not a lot of point unless I only
talk to myself..

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Date: Mon, 29 Oct 2001 00:43:37 +0100
From: Chris Lilley <[email-masked]>
To: Elliotte Rusty Harold <[email-masked]>
CC: [email-masked]
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Sender: [email-masked]

Elliotte Rusty Harold wrote:
> 
> Among other things, this means that the same document may be interpreted with a different encoding when read from HTTP than when read from the local file system. YUCK! This is a major interoperability problem.

I agree and I have always asserted that same position. I feel that the
xml encoding declaration, which is under the authors control and is
creatable in a standard form by any authoring software, is a far more
secure an error-free way to indicate the encoding than to rely on the
vagarities of how (if at all) some server is set up to generate charset
parameters and what meands (separate files, filename conventions, etc)
it uses to trigger such behavior.

Those people who wish to use non-xml-aware transcoders to do content
encoding conversion and were not willing to have those encoders made
xml-aware enough to alter the xml encoding declaration when transcoding,
won (unfortunately, in my view) and as a result, for application/xml as
wel as for text/xml, the charset patrameter *whether present or absent*
overrides the encoding declaration in the xml file. 

Thus, simplicity for charset transcoder is achieved at the expense of
compexity for all xml clients, which have to perform a check and
potentially rewrite the xml file when saving to disk, assuming they want
it to be parsed afterwards.

> 
> Perhaps worse yet, since the default for text/xml is us-ascii and not utf-8, this means that serving an XML document using any non-ASCII characters over HTTP requires the author to set the charset parameter of the MIME media type. This is non-trivial in most environments and impossible in many. 

Correct.

> According to RFC 3023, "US-ASCII was chosen, since it is the intersection of UTF-8 and ISO-8859-1 and since it is already used by MIME." However, this really strikes me as insufficient justification given the major practical problems it presents for non-ASCII documents. 

This was chosen to retain backwards compatibility with what the MIME
spec allows for any text/* document - treat it as text/plain.

> Is there any chance of superseding this RFC with one that specifies UTF-8? This still isn't perfect, but it at least allows full use of Unicode.
> 
> Interestingly, application/xml does not have this problem, at least not all of it.

Yes, although prior to this RFC, application/* had *none* of it because
there was no charset.

> In the absence of an explicit charset parameter, then application/xml falls back to the normal heuristics for guessing the encoding of an XML document (e.g. byte order mark, encoding declaration, etc.) 

Thus, all xml content should be served as applicvation/xml and use of
text/xml should be deprecated.

> There's still a problem if the MIME charset disagrees with the document internal information, 

Yes. One of the things that can be done in practival terms is to make it
an error if these disagree.

> but in practice this isn't nearly as big a problem. Maybe that's what should be done with text/xml as well? It certainly seems to be what Mozilla is already doing.
> 
> In the meantime, I think I'm going to start recommending the use of application/xml and deprecating the use of text/xml.

I agree. Due to the legacy requirements of text/* types, it is really
not very suitable for XML.

-- 
Chris

From: "Dan Kohn" <[email-masked]>
To: "'David Carlisle'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [xml-dev] Registration status
Date: Sun, 28 Oct 2001 14:40:59 -0800
Importance: Normal
Sender: [email-masked]

David, as the co-author of RFC 3023, I would appreciate if you would
reread it.  We covered these issues in an extensive mailing list
archive, but tried to distill them into appendix A.

Specifically, MIME is not solely handled by web browsers.  Email agents
are also MIME dispatchers, as are NNTP and BEEP clients (and soon IM).
It is very unlikely that all XML-based MIME types seen by these agents
(none of which currently understand namespaces, although at least BEEP
parses XML) should be dispatched to the same XML application.  Think
application/calendar+xml versus image/svg+xml.

Now, I agree that compound types cannot be handled ideally by MIME, but
the MIME concept of dispatching to the correct application is still
useful.  In particular, an XHTML+MathML document quite possibly needs to
be handled by a different application (say Mozilla) than default unknown
XML types (which might want XML Spy).

As to web hosting, I agree that users need more control over MIME types
than they're currently getting.  Although it's not a good ultimate
solution, the use of file suffixes has served as an implicit mapping for
MIME types.  Thus, web servers can (and, IMHO, should) be configured so
that .xhtml is served as application/xhtml+xml and .xml as
application/xml.  Things like XHTML+MathML documents that are likely to
be successfully dispatched using namespaces by XHTML renderers should
use the .xhtml extension and application/xhtml+xml.

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.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Carlisle
Sent: Sunday, October 28, 2001 14:15
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [xml-dev] Registration status

> I doubt that's necessary in the general case.  It is typically
> sufficient that the media type is used to dispatch the processor
> that recognizes the root element, permitting further internal
> namespace dispatching independant of the media type.  That's the
> case for XHTML at least.

I'm not sure I follow this at all. You use the present case, but are
there any current applications that would work if the document was sent
as xhtml+xml but wouldn't if it was sent as xml? If the xnl file is
explicitly styled (with xslt or css) then surely just xml semantics is
sufficient. If not, then having it sent as xhtml+xml might allow a
default style to be applied (but as mozilla shows that's possible just
using the namespace, and the latter has definite advantages when you
discover elements in the mathml namespace half way down the page)

> This [dispatching on namespace] will happen eventually, but it can't
> yet be assumed that a receiving agent will dispatch on a namespace, or
> have any means of configuring namespace/processor bindings.  So for
> the next little while, there'll be some value in media types.

I'm not sure. Today I can have an xhtml+mathml document and on any
processor with a client side xslt (IE5/msxml3,IE6,Mozilla,NS6) I can
cause "whatever is needed" to happen on the client side by having the
client side XSLT transform the inline namespaced elements to whatever
that client needs to display that language. This works now, but a) I
don't know when the clients will be able to handle *+xml mime types out
of the box, and I don't know when if ever "basic" ISP's will allow
customisation of the outgoing types.

I want it to be as easy to put a xhtml+mathml page on the web as it is
to put an html page including tables. ie anyone with a dialup account to
ought be able to do it. If it means configuring the server to send
different mime types depending what's in the document, it doesn't really
work.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Date: Sun, 28 Oct 2001 22:14:48 GMT
From: David Carlisle <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

> I doubt that's necessary in the general case.  It is typically
> sufficient that the media type is used to dispatch the processor
> that recognizes the root element, permitting further internal
> namespace dispatching independant of the media type.  That's the
> case for XHTML at least.

I'm not sure I follow this at all. You use the present case, but are
there any current applications that would work if the document was sent
as xhtml+xml but wouldn't if it was sent as xml? If the xnl file is
explicitly styled (with xslt or css) then surely just xml semantics is
sufficient. If not, then having it sent as xhtml+xml might allow a
default style to be applied (but as mozilla shows that's possible just
using the namespace, and the latter has definite advantages when you
discover elements in the mathml namespace half way down the page)

> This [dispatching on namespace] will happen eventually, but it can't
> yet be assumed that a receiving agent will dispatch on a namespace, or
> have any means of configuring namespace/processor bindings.  So for
> the next little while, there'll be some value in media types.

I'm not sure. Today I can have an xhtml+mathml document and on any
processor with a client side xslt (IE5/msxml3,IE6,Mozilla,NS6) I can
cause "whatever is needed" to happen on the client side by having the
client side XSLT transform the inline namespaced elements to whatever
that client needs to display that language. This works now, but a) I
don't know when the clients will be able to handle *+xml mime types out
of the box, and I don't know when if ever "basic" ISP's will allow
customisation of the outgoing types.

I want it to be as easy to put a xhtml+mathml page on the web as it is
to put an html page including tables. ie anyone with a dialup account to
ought be able to do it. If it means configuring the server to send
different mime types depending what's in the document, it doesn't really
work.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Date: Sun, 28 Oct 2001 21:59:30 GMT
From: David Carlisle <[email-masked]>
To: [email-masked]
Subject:  Re: [xml-dev] Registration status
Sender: [email-masked]

[re-send as original posting blocked on this list, please keep xml-dev
in the loop on any reply, David]

>  >From owner-ietf-xml-mime Sun Oct 28 09:53:05 2001
>Received: from mail17.messagelabs.com (mail17.messagelabs.com [62.231.131.67])
>	by above.proper.com (8.11.6/8.11.3) with SMTP id f9SHr4816713
>	for <[email-masked]>; Sun, 28 Oct 2001 09:53:04 -0800 (PST)
>X-VirusChecked: Checked
>Received: (qmail 11174 invoked from network); 28 Oct 2001 17:46:49 -0000
>Received: from unknown (HELO nag.co.uk) (62.231.145.242)
>   by server-5.tower-17.messagelabs.com with SMTP; 28 Oct 2001 17:46:49 -0000
>Received: from penguin.nag.co.uk (IDENT:[email-masked] 
>[192.156.217.14])
>	by nag.co.uk (8.9.3/8.9.3) with ESMTP id RAA00934;
>	Sun, 28 Oct 2001 17:52:40 GMT
>Date: Sun, 28 Oct 2001 17:52:38 GMT
>Message-Id: <[email-masked]>
>Received: by penguin.nag.co.uk (8.9.3) id RAA10002; Sun, 28 Oct 2001 
>17:52:38 GMT
>From: David Carlisle <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked]
>In-reply-to: <[email-masked]> (message from Elliotte Rusty
>	Harold on Sat, 27 Oct 2001 19:46:04 -0700)
>Subject: Re: [xml-dev] Registration status
>References:  <[email-masked]>
>
>
>There's been some thought about doing it but I think we're watching
>the progress of the html group's html+xml draft first. (speaking about
>MathML here)
>
>But personally the more I think about this, the less I like it, and see
>so little use for media types for XML languages. Except for test files
>MathML never lives on its own, it's always embedded in a larger document
>type, XHTML, DocBook, TEI, whatever. Since the same document might also
>have svg, you end up with application/xhtml+mathml+svg+xml and
>permutations of that. It seems unreasonable to expect any application to
>do anything with that and in practice a more workable alternative is to
>serve everything as application/xml and let the application key
>individual processing requirements off the namespaces contained in the
>document. (Actually my "home" isp will serve .xml files as text/xml with
>no possibility of changing that, but that's a different thread)
>
>David
>

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Date: Sun, 28 Oct 2001 16:44:56 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: [email-masked]
Subject: Re: [xml-dev] Registration status (fwd)
Sender: [email-masked]

---------- Forwarded message ----------

>cc: [email-masked], [email-masked], [email-masked]
>
>
>On Sun, 28 Oct 2001, David Carlisle wrote:
>
>>
>>  There's been some thought about doing it but I think we're watching
>>  the progress of the html group's html+xml draft first. (speaking about
>>  MathML here)
>>
>>  But personally the more I think about this, the less I like it, and see
>>  so little use for media types for XML languages. Except for test files
>>  MathML never lives on its own, it's always embedded in a larger document
>>  type, XHTML, DocBook, TEI, whatever. Since the same document might also
>>  have svg, you end up with application/xhtml+mathml+svg+xml and
>>  permutations of that. It seems unreasonable to expect any application to
>>  do anything with that and in practice a more workable alternative is to
>>  serve everything as application/xml and let the application key
>>  individual processing requirements off the namespaces contained in the
>>  document. (Actually my "home" isp will serve .xml files as text/xml with
>>  no possibility of changing that, but that's a different thread)
>
>I had a similar argument about this with Simon about a year ago (maybe
>longer). I too felt that the MIME mechanism should simply state the 'raw'
>type, and the handler should decide the specifics of the processing. 
>Your example nicely illustrates the rational for this point of view.
>
>However, RFC 3023 does expliclity talk about this, in Appendix A. The
>issue really is that, without the +xml trick, new MIME types would
>logically want to identify types by their role -- as in image/svg -- which
>would mean that a non-svg aware applicaiton wouldn't know that the data is
>XML.  If it did -- which is what xml+svg gives you -- then the software
>could perhaps offer appropriate alternate processing.
>
>The core questions, I think, are:
>   * how 'deeply' MIME types (or some future variant of the MIME typing
>     mechanism) should poke into the data they are 'typing'?
>   * And, if they poke deeply, what type of/how much information should be
>     revealed?
>
>An alternative would be to ask the question: "How can one structure XML so
>that a 'shallow' look into an XML 'part' can determine which 'types' are
>inside it?" Namespace declarations would do this to some degree, but at
>the expense of forcing a dispatcher to parse the XML.
>
>Ian

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: Re: [xml-dev] Registration status
To: [email-masked] (David Carlisle)
Date: Sun, 28 Oct 2001 16:50:28 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

> But personally the more I think about this, the less I like it, and see
> so little use for media types for XML languages. Except for test files
> MathML never lives on its own, it's always embedded in a larger document
> type, XHTML, DocBook, TEI, whatever. Since the same document might also
> have svg, you end up with application/xhtml+mathml+svg+xml and
> permutations of that.

I doubt that's necessary in the general case.  It is typically
sufficient that the media type is used to dispatch the processor
that recognizes the root element, permitting further internal
namespace dispatching independant of the media type.  That's the
case for XHTML at least.

> It seems unreasonable to expect any application to
> do anything with that and in practice a more workable alternative is to
> serve everything as application/xml and let the application key
> individual processing requirements off the namespaces contained in the
> document. (Actually my "home" isp will serve .xml files as text/xml with
> no possibility of changing that, but that's a different thread)

This will happen eventually, but it can't yet be assumed that a
receiving agent will dispatch on a namespace, or have any means
of configuring namespace/processor bindings.  So for the next
little while, there'll be some value in media types.

MB
-- 
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
[email-masked]

Date: Sun, 28 Oct 2001 19:18:40 +0100
From: Chris Lilley <[email-masked]>
To: Elliotte Rusty Harold <[email-masked]>
CC: [email-masked], xml-dev <[email-masked]>
Subject: Re: Registration status
Sender: [email-masked]

Elliotte Rusty Harold wrote:
> 
> RFC 3023 states that for application/mathml+xml, "no content type has
> yet  been registered for MathML and so this media type should not be
> used until such registration has been completed." Similar statements are
> given for SVG, RDF, and XSLT.

However, the W3C Recommendation for SVG does define the image/svg+xml
MIME type and people have been using it for a year (since it changed
from image/svg-xml which was what the internet draft preceeding RFC 3023
used to say).

> What is the current status of these registrations? None of them have
> made it through the IANA registration. 

The registration for SVG is in development, but has not yet been sent to
IANA.

> At least none of them are listed
> at http://www.isi.edu/in-notes/iana/assignments/media-types/application/
> 
> Has anybody actually begun the process of registering these four types?

Yes, the W3C SVG WG is working on it. Discussion hinges on such details
as whether to allow/require/disallow a charset (which would be a first
for image/* and would require more detailed server setup) and an
analysis of security considerations.

-- 
Chris

Date: Sat, 27 Oct 2001 21:02:06 -0400
To: [email-masked]
From: Elliotte Rusty Harold <[email-masked]>
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Cc: [email-masked]
Sender: [email-masked]

I noticed that Apache 1.3.22 and 2.0 use text/xml by default. I just filed a bug report with them to change that to application/xml and referenced this thread. In the meantime, Apache users might want to edit mime.types to change this manually. If that file is not accessible, you can use the AddType directive in your .htaccess file to override the server wide defaults. See http://httpd.apache.org/docs/mod/mod_mime.html for details on AddType, AddCharset, and similar useful directives. 
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | [email-masked] | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+

From: Bjoern Hoehrmann <[email-masked]>
To: Elliotte Rusty Harold <[email-masked]>
Cc: [email-masked], xml-dev <[email-masked]>
Subject: Re: Registration status
Date: Sun, 28 Oct 2001 02:58:14 +0200
Organization: none
Sender: [email-masked]

* Elliotte Rusty Harold wrote:
>RFC 3023 states that for application/mathml+xml, "no content type has 
>yet  been registered for MathML and so this media type should not be 
>used until such registration has been completed." Similar statements are 
>given for SVG, RDF, and XSLT.
>
>What is the current status of these registrations? None of them have 
>made it through the IANA registration. At least none of them are listed 
>at http://www.isi.edu/in-notes/iana/assignments/media-types/application/
>
>Has anybody actually begun the process of registering these four types?

Chris Lilley will eventually go and register image/svg+xml (see
[email-masked] discussion), no Internet-Draft yet.

Aaron Swartz and Daniel Connolly wrote a draft of an internet draft,
http://blogspace.com/rdf/mimetype.txt for application/rdf+xml, no
Internet-Draft yet.

In case of XSLT, the only widely deployed media type is text/xsl, also
unregistered, this has been discussed here, no Internet-Draft for any of
those types. No Internet-Draft for MathML, dunno about any plans.

There is an internet draft for application/smil and
application/smil+xml, see draft-hoschka-smil-media-type-09.txt, as there
is for application/xhtml+xml, see draft-baker-xhtml-media-reg-02.txt,
it's even in Last Call.

Three +xml types are already registered, for BEEP, XUL and whatever
application/vnd.irepository.package+xml is for.
-- 
Björn Höhrmann { mailto:[email-masked] } 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/

Date: Sat, 27 Oct 2001 19:46:04 -0700
From: Elliotte Rusty Harold <[email-masked]>
To: [email-masked]
CC: xml-dev <[email-masked]>
Subject: Registration status
Sender: [email-masked]

RFC 3023 states that for application/mathml+xml, "no content type has 
yet  been registered for MathML and so this media type should not be 
used until such registration has been completed." Similar statements are 
given for SVG, RDF, and XSLT.

What is the current status of these registrations? None of them have 
made it through the IANA registration. At least none of them are listed 
at http://www.isi.edu/in-notes/iana/assignments/media-types/application/

Has anybody actually begun the process of registering these four types?

-- 
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | [email-masked] | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|               Java I/O (O'Reilly & Associates, 1999)               |
|            http://www.ibiblio.org/javafaq/books/javaio/            |
|   http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+

Date: Sat, 27 Oct 2001 10:40:16 -0700
To: [email-masked], [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Sender: [email-masked]

At 11:59 AM 27/10/01 -0400, John Cowan wrote:
>Elliotte Rusty Harold scripsit:
>> In the meantime, I think I'm going to start recommending the use of
>> application/xml and deprecating the use of text/xml. 

>Absolutely; as one poster said, it is one of the most important moves.
>It almost never makes sense to use text/xml, unless your text is cleverly
>arranged to be both WF XML and readable to someone who never heard of XML
>*or* i18n.

Hmm... in practical terms, using text/xml doesn't usually break
things, since most actual software, near as I can tell, cheerfully
ignores the RFC rules and figures out the actual encoding.

Doesn't mean the folks posting on this are wrong.  application/xml
is less likely to cause breakage when rules are being followed, 
and it's really hard to think of a good reason to use text/xml.  In 
particular, it seems counter-intuitive to expect J. Random Webserver
to know what encoding it's shipping out in the general case. 

-Tim

Date: Sat, 27 Oct 2001 04:54:56 -0400
To: [email-masked]
From: Elliotte Rusty Harold <[email-masked]>
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Cc: [email-masked]
Sender: [email-masked]

Among other things, this means that the same document may be interpreted with a different encoding when read from HTTP than when read from the local file system. YUCK! This is a major interoperability problem. 

Perhaps worse yet, since the default for text/xml is us-ascii and not utf-8, this means that serving an XML document using any non-ASCII characters over HTTP requires the author to set the charset parameter of the MIME media type. This is non-trivial in most environments and impossible in many. According to RFC 3023, "US-ASCII was chosen, since it is the intersection of UTF-8 and ISO-8859-1 and since it is already used by MIME." However, this really strikes me as insufficient justification given the major practical problems it presents for non-ASCII documents. Is there any chance of superseding this RFC with one that specifies UTF-8? This still isn't perfect, but it at least allows full use of Unicode. 

Interestingly, application/xml does not have this problem, at least not all of it. In the absence of an explicit charset parameter, then application/xml falls back to the normal heuristics for guessing the encoding of an XML document (e.g. byte order mark, encoding declaration, etc.) There's still a problem if the MIME charset disagrees with the document internal information, but in practice this isn't nearly as big a problem. Maybe that's what should be done with text/xml as well? It certainly seems to be what Mozilla is already doing. 

In the meantime, I think I'm going to start recommending the use of application/xml and deprecating the use of text/xml. 
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | [email-masked] | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+

From: Michael Brennan <[email-masked]>
To: "'Bjoern Hoehrmann'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [xml-dev] Text/xml with omitted charset parameter
Date: Fri, 26 Oct 2001 12:45:41 -0700
Sender: [email-masked]

> From: Bjoern Hoehrmann [mailto:[email-masked]]

<snip/>

> XML only works with 100% standards compliance, xml-dev people will go
> and advocate it. Considering the amount of people who complained about
> IE accepting invalid characters in XML documents, soon all product
> developers and content providers will have their products and content
> fixed. 

I agree with you, there. I've been pretty outspoken on this particular issue
in the past on this list and others. I think the situation is improving.
More developers are becoming aware of this.

I know, for instance, that at one point virtually none of the SOAP toolkits
on the market were including a charset parameter on the Content-Type header.
But this issue was raised on the Yahoo soapbuilders list, and toolkit
implementors worked together to make sure this issue was addressed, and that
the various toolkits handled character encoding issues in a fashion that is
interoperable and complies with the relevant specs.

So we just need to keep educating people about this, and things will
continue to improve.

I think we also need to learn the lessons from what has happened on the web.
The idea of having forgiving tools sounds great in theory, but it encourages
sloppy practices on the part of developers. It is because of "forgiving"
browsers that we have a web populated with malformed HTML content. We should
try not to repeat that mistake with XML.

From: Bjoern Hoehrmann <[email-masked]>
To: Michael Brennan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [xml-dev] Text/xml with omitted charset parameter
Date: Fri, 26 Oct 2001 04:42:01 +0200
Organization: none
Sender: [email-masked]

* Michael Brennan wrote:
>Mentioning UTF-16 in this example is not absurd at all.

It is at least misleading, since it doesn't say,
this case is invalid and won't work. In fact, it
implies the contrary to me.

>And yes, just serving up "text/xml" with no charset parameter is asking for
>interoperability problems. But to be honest, this RFC is widely violated by
>many software packages and products on the market.

>Unfortunately, there is a hell of a lot of software out there that just uses
>"text/xml" with no charset parameter. Apache certainly isn't the only
>offender. So when you want to write software that can accept XML via HTTP or
>within MIME envelopes, you are going to encounter interoperability headaches
>no matter what.

XML only works with 100% standards compliance, xml-dev people will go
and advocate it. Considering the amount of people who complained about
IE accepting invalid characters in XML documents, soon all product
developers and content providers will have their products and content
fixed. IE6 is the first identified offender, someone shall go and blame
Microsoft.

Thanks for your clarification.
-- 
Björn Höhrmann { mailto:[email-masked] } 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/

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Text/xml with omitted charset parameter
Date: Fri, 26 Oct 2001 03:07:04 +0200
Organization: none
Sender: [email-masked]

Hi,

Quoting RFC 3023, section 8.5:

| 8.5 Text/xml with Omitted Charset
| 
|    Content-type: text/xml
| 
|    {BOM}<?xml version="1.0" encoding="utf-16"?>
| 
|    or
| 
|    {BOM}<?xml version="1.0"?>
| 
|    This example shows text/xml with the charset parameter omitted.  In
|    this case, MIME and XML processors MUST assume the charset is "us-
|    ascii",

... and issue a fatal error, no BOM in US-ASCII. Mentioning UTF-16 in
this example is absurd, XML documents labeled as text/xml without
charset parameter can never ever be UTF-16 encoded. So, who tells me I
am wrong and text/xml documents without charset parameter may still be
UTF-8 encoded (and use non-ASCII characters)? Apache uses text/xml as
default type for .xml documents, are they asking for interoperability
problems or what?
-- 
Björn Höhrmann { mailto:[email-masked] } 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/

Subject: Re: Preparing for XPointer
From: "Simon St.Laurent" <[email-masked]>
To: Mark Baker <[email-masked]>
Cc: [email-masked]
Date: 24 Oct 2001 16:03:12 -0400
Sender: [email-masked]

On Wed, 2001-10-24 at 14:18, Mark Baker wrote:
> During that thought experiment, it occurred to me that we should
> be watching +xml registrations to ensure that, where possible,
> "#foo" syntax is reserved for identifying fragments labelled with
> an ID (or http://www.w3.org/2001/XMLSchema#id) type attribute of
> value "foo".
> 
> This would ensure that XPointer could be be retrofitted into
> 3023 later and apply to all */xml and */*+xml types.

It seems like a reasonable idea.  In some ways, #foo is pretty much
MinPointer, the one part of XPointer about which I hear no complaints.

-- 
Simon St.Laurent
"Every day, in every way, I'm getting better and better." - Emile Coue

Subject: Re: Preparing for XPointer
To: [email-masked] (Bjoern Hoehrmann)
Date: Wed, 24 Oct 2001 15:49:41 -0400 (EDT)
Cc: [email-masked]
From: Mark Baker <[email-masked]>
Sender: [email-masked]

> * Mark Baker wrote:
> >In working on the registration of application/xhtml+xml, one of the
> >issues was how to best handle a possible transition to XPointer.
> >
> >During that thought experiment, it occurred to me that we should
> >be watching +xml registrations to ensure that, where possible,
> >"#foo" syntax is reserved for identifying fragments labelled with
> >an ID (or http://www.w3.org/2001/XMLSchema#id) type attribute of
> >value "foo".
> 
> XPointer does this, as I've said, in Section 4.2.2, "Bare Names".

You misunderstood.

My point is that if somebody goes out and registers application/bar+xml
tomorrow, and it defines "#foo" to mean something other than ID-based
fragment idenfication, then 3023 will have difficulty integrating XPointer
later because it cannot state that all +xml types will have the same
fragment identification behaviour.

Like I say, the chances are slim of this happening, but it's still,
IMO, an important enough issue to raise (assuming you like XPointer 8-).

MB
-- 
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
[email-masked]

From: Bjoern Hoehrmann <[email-masked]>
To: Mark Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: Preparing for XPointer
Date: Wed, 24 Oct 2001 21:24:26 +0200
Organization: none
Sender: [email-masked]

* Mark Baker wrote:
>In working on the registration of application/xhtml+xml, one of the
>issues was how to best handle a possible transition to XPointer.
>
>During that thought experiment, it occurred to me that we should
>be watching +xml registrations to ensure that, where possible,
>"#foo" syntax is reserved for identifying fragments labelled with
>an ID (or http://www.w3.org/2001/XMLSchema#id) type attribute of
>value "foo".

XPointer does this, as I've said, in Section 4.2.2, "Bare Names".
-- 
Björn Höhrmann { mailto:[email-masked] } 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/

Subject: Preparing for XPointer
To: [email-masked]
Date: Wed, 24 Oct 2001 14:18:29 -0400 (EDT)
From: Mark Baker <[email-masked]>
Sender: [email-masked]

Hi all,

In working on the registration of application/xhtml+xml, one of the
issues was how to best handle a possible transition to XPointer.

During that thought experiment, it occurred to me that we should
be watching +xml registrations to ensure that, where possible,
"#foo" syntax is reserved for identifying fragments labelled with
an ID (or http://www.w3.org/2001/XMLSchema#id) type attribute of
value "foo".

This would ensure that XPointer could be be retrofitted into
3023 later and apply to all */xml and */*+xml types.

I would expect this to be the case anyhow, but I thought it worth
mentioning.

MB
-- 
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
[email-masked]