Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9V0SUp22912 for ietf-xml-mime-bks; Tue, 30 Oct 2001 16:28:30 -0800 (PST) Received: from mail.asahi-net.or.jp (mail.asahi-net.or.jp [202.224.39.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V0SS822906 for ; Tue, 30 Oct 2001 16:28:28 -0800 (PST) Received: from localhost (h223219.ppp.asahi-net.or.jp [61.114.223.219]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 3D106681B; Wed, 31 Oct 2001 09:28:30 +0900 (JST) Date: Sun, 28 Oct 2001 00:32:09 +0900 (JST) Message-Id: <20011028.003209.01369130.muraw3c@attglobal.net> To: derhoermi@gmx.net Cc: Michael_Brennan@Allegis.com, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Text/xml with omitted charset parameter From: MURATA Makoto In-Reply-To: References: <753B28EF1C2DD411AF1C00B0D0202CB502480BF5@mailhost.hq.allegis.com> X-Mailer: Mew version 2.1rc1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Bjoern Hoehrmann 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U4d4i27062 for ietf-xml-mime-bks; Mon, 29 Oct 2001 20:39:04 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9U4d3827058 for ; Mon, 29 Oct 2001 20:39:03 -0800 (PST) Received: (qmail 19497 invoked by uid 0); 30 Oct 2001 04:38:59 -0000 Received: from pd903b363.dip.t-dialin.net (217.3.179.99) by mail.gmx.net (mp005-rz3) with SMTP; 30 Oct 2001 04:38:59 -0000 From: Bjoern Hoehrmann To: "Henrik Frystyk Nielsen" Cc: , , , "Mark Nottingham" Subject: Re: Question on status of '+xml' notation Date: Tue, 30 Oct 2001 05:37:57 +0100 Organization: none Message-ID: References: <79107D208BA38C45A4E45F62673A434D055AACF4@red-msg-07.redmond.corp.microsoft.com> In-Reply-To: <79107D208BA38C45A4E45F62673A434D055AACF4@red-msg-07.redmond.corp.microsoft.com> X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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: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/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9U3Row25446 for ietf-xml-mime-bks; Mon, 29 Oct 2001 19:27:50 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U3Rn825442 for ; Mon, 29 Oct 2001 19:27:49 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KA2L0RTKI80013KR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Mon, 29 Oct 2001 19:27:50 -0800 (PST) Date: Mon, 29 Oct 2001 19:23:47 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: Re: Question on status of '+xml' notation In-reply-to: "Your message dated Mon, 29 Oct 2001 09:53:38 -0800" <79107D208BA38C45A4E45F62673A434D055AACF4@red-msg-07.redmond.corp.microsoft.com> To: Henrik Frystyk Nielsen Cc: ietf-xml-mime@imc.org, hugo@w3.org, ylafon@w3.org, Mark Nottingham Message-id: <01KA322B2FGU0013KR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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 Received: by above.proper.com (8.11.6/8.11.3) id f9U2ED123900 for ietf-xml-mime-bks; Mon, 29 Oct 2001 18:14:13 -0800 (PST) Received: from mercury.ccil.org (mail@mercury.ccil.org [192.190.237.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U2EC823895 for ; Mon, 29 Oct 2001 18:14:12 -0800 (PST) Received: from cowan by mercury.ccil.org with local (Exim 3.12 #1 (Debian)) id 15yOPm-0006Ad-00; Mon, 29 Oct 2001 21:14:06 -0500 Subject: Re: [xml-dev] Re: determining ID-ness in XML In-Reply-To: <20011029165632.L9703@redhat.com> from Daniel Veillard at "Oct 29, 2001 04:56:32 pm" To: veillard@redhat.com Date: Mon, 29 Oct 2001 21:14:06 -0500 (EST) CC: Tim Bray , ietf-xml-mime@imc.org, xml-dev@lists.xml.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: John Cowan Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 cowan@ccil.org 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TNI0619727 for ietf-xml-mime-bks; Mon, 29 Oct 2001 15:18:00 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TNHw819723 for ; Mon, 29 Oct 2001 15:17:58 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KA2L0RTKI80013KR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Mon, 29 Oct 2001 15:17:50 -0800 (PST) Date: Mon, 29 Oct 2001 15:12:07 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: Re: [xml-dev] Registration status In-reply-to: "Your message dated Mon, 29 Oct 2001 09:44:40 +0000 (GMT)" <200110290944.JAA11486@penguin.nag.co.uk> To: David Carlisle Cc: dan@dankohn.com, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Message-id: <01KA2TBDQEL40013KR@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <00e201c16012$9b69bb00$6401a8c0@skymoonventures.com> <00e201c16012$9b69bb00$6401a8c0@skymoonventures.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TN4Fe19403 for ietf-xml-mime-bks; Mon, 29 Oct 2001 15:04:15 -0800 (PST) Received: from hq14.pcmail.ingr.com ([63.75.137.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TN4E819398 for ; Mon, 29 Oct 2001 15:04:14 -0800 (PST) Received: by HQ14 with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Oct 2001 17:04:12 -0600 Message-ID: <2C61CCE8A870D211A523080009B94E43068BEF6F@HQ5> From: "Bullard, Claude L (Len)" To: veillard@redhat.com, "Champion, Mike" Cc: Tim Bray , ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: RE: [xml-dev] Re: determining ID-ness in XML Date: Mon, 29 Oct 2001 17:04:11 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:veillard@redhat.com] 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 !) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TMk8J18944 for ietf-xml-mime-bks; Mon, 29 Oct 2001 14:46:08 -0800 (PST) Received: from hq15.pcmail.ingr.com ([63.75.137.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TMk7818940 for ; Mon, 29 Oct 2001 14:46:07 -0800 (PST) Received: by HQ15 with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Oct 2001 16:45:56 -0600 Message-ID: <2C61CCE8A870D211A523080009B94E43068BEF47@HQ5> From: "Bullard, Claude L (Len)" To: "Champion, Mike" , veillard@redhat.com, Tim Bray Cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: RE: [xml-dev] Re: determining ID-ness in XML Date: Mon, 29 Oct 2001 16:45:54 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That's a crock, Mike. len -----Original Message----- From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 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? Received: by above.proper.com (8.11.6/8.11.3) id f9TMTnt18426 for ietf-xml-mime-bks; Mon, 29 Oct 2001 14:29:49 -0800 (PST) Received: from usmsg05.sagus.com ([157.189.11.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TMTm818419 for ; Mon, 29 Oct 2001 14:29:49 -0800 (PST) Received: from usmsg04.sagus.com (usrsfw3.sagus.com [157.189.2.109]) by usmsg05.sagus.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4A5N3GA8; Mon, 29 Oct 2001 17:29:50 -0500 Received: by usmsg04.sagus.com with Internet Mail Service (5.5.2653.19) id <4A5LQQJL>; Mon, 29 Oct 2001 17:29:50 -0500 Message-ID: <9A4FC925410C024792B85198DF1E97E401A84E1C@usmsg03.sagus.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Champion, Mike" To: veillard@redhat.com, Tim Bray Cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: RE: [xml-dev] Re: determining ID-ness in XML Date: Mon, 29 Oct 2001 17:29:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: Monday, October 29, 2001 4:57 PM > To: Tim Bray > Cc: ietf-xml-mime@imc.org; xml-dev@lists.xml.org > 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? Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TJhiA11716 for ietf-xml-mime-bks; Mon, 29 Oct 2001 11:43:44 -0800 (PST) Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TJhc811710 for ; Mon, 29 Oct 2001 11:43:43 -0800 (PST) Received: from krypton ([206.170.6.140]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GLZ00AWNG4QLN@mta6.snfc21.pbi.net> for ietf-xml-mime@imc.org; Mon, 29 Oct 2001 11:43:39 -0800 (PST) Date: Mon, 29 Oct 2001 11:42:18 -0800 From: David Brownell Subject: Re: [xml-dev] Re: determining ID-ness in XML To: Tom Bradford Cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Message-id: <1f0201c160b1$d27bef60$6800000a@brownell.org> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >> 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 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? Received: by above.proper.com (8.11.6/8.11.3) id f9TJemh11657 for ietf-xml-mime-bks; Mon, 29 Oct 2001 11:40:48 -0800 (PST) Received: from usmsg05.sagus.com ([157.189.11.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TJel811653 for ; Mon, 29 Oct 2001 11:40:47 -0800 (PST) Received: from usmsg04.sagus.com (usrsfw3.sagus.com [157.189.2.109]) by usmsg05.sagus.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 4A5N3C2R; Mon, 29 Oct 2001 14:40:49 -0500 Received: by usmsg04.sagus.com with Internet Mail Service (5.5.2653.19) id <4A5LQ3J7>; Mon, 29 Oct 2001 14:40:49 -0500 Message-ID: <9A4FC925410C024792B85198DF1E97E401A84D88@usmsg03.sagus.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Champion, Mike" To: "Fred L. Drake, Jr." , "Champion, Mike" Cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: RE: [xml-dev] Re: determining ID-ness in XML Date: Mon, 29 Oct 2001 14:40:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Fred L. Drake, Jr. [mailto:fdrake@acm.org] > 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! Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TIrpl09733 for ietf-xml-mime-bks; Mon, 29 Oct 2001 10:53:51 -0800 (PST) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TIrn809729 for ; Mon, 29 Oct 2001 10:53:49 -0800 (PST) Received: from rune.antarcti.ca (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id E948010A23; Mon, 29 Oct 2001 10:53:45 -0800 (PST) Message-Id: <5.1.0.14.2.20011029103651.020795f0@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Oct 2001 10:53:41 -0800 To: ietf-xml-mime@imc.org, xml-dev@lists.xml.org From: Tim Bray Subject: Re: determining ID-ness in XML In-Reply-To: <4.3.2.7.2.20011029083547.017b1098@172.27.10.30> References: <5.1.0.14.2.20011028204136.02072790@pop.intergate.ca> <3BDCC3C6.86A9FA0B@w3.org> <200110241818.OAA14482@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [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: ... 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 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 ... ... 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9THrwb06681 for ietf-xml-mime-bks; Mon, 29 Oct 2001 09:53:58 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THrv806677 for ; Mon, 29 Oct 2001 09:53:57 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Oct 2001 09:53:39 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Oct 2001 09:53:38 -0800 Received: from red-msg-07.redmond.corp.microsoft.com ([157.54.12.75]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 29 Oct 2001 09:53:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Question on status of '+xml' notation Date: Mon, 29 Oct 2001 09:53:38 -0800 Message-ID: <79107D208BA38C45A4E45F62673A434D055AACF4@red-msg-07.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on status of '+xml' notation thread-index: AcFgoqKgVF6WwY9KRlC8O7ld04QTpQ== From: "Henrik Frystyk Nielsen" To: , , Cc: "Mark Nottingham" X-OriginalArrivalTime: 29 Oct 2001 17:53:38.0586 (UTC) FILETIME=[A36CA7A0:01C160A2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9THrv806678 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TFlLP24726 for ietf-xml-mime-bks; Mon, 29 Oct 2001 07:47:21 -0800 (PST) Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TFlI824715 for ; Mon, 29 Oct 2001 07:47:18 -0800 (PST) Received: from fwd03.sul.t-online.de by mailout05.sul.t-online.de with smtp id 15yEd7-0008W8-0N; Mon, 29 Oct 2001 16:47:13 +0100 Received: from nobis (320029994702-0001@[217.5.89.100]) by fwd03.sul.t-online.com with smtp id 15yEd3-0GcMFsC; Mon, 29 Oct 2001 16:47:09 +0100 Received: from 192.168.115.1:1421 by KEN! DSL (0.0.0.0:25) with SMTP Mon Oct 29 16:39:28 2001 +0100 Message-Id: <007a01c16090$ad4ac480$fe78a8c0@vobis> Reply-To: "Jens-H. Niggemeyer" From: jensnig@t-online.de (Jens-H. Niggemeyer) To: Subject: Fw: jensnig@localwhiz.com Date: Mon, 29 Oct 2001 16:45:02 +0100 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C16099.0E46FA80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 320029994702-0001@t-dialin.net Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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: ietf-xml-mime@imc.org=20 Sent: Monday, October 29, 2001 10:16 AM Subject: jensnig@localwhiz.com unsubscribe jensnig@localwhiz.com ------=_NextPart_000_0077_01C16099.0E46FA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
----- Original Message -----=20
From: Jens-H.=20 Niggemeyer
Sent: Monday, October 29, 2001 10:16 AM
Subject: jensnig@localwhiz.com

unsubscribe jensnig@localwhiz.com
------=_NextPart_000_0077_01C16099.0E46FA80-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9TEnbN22797 for ietf-xml-mime-bks; Mon, 29 Oct 2001 06:49:37 -0800 (PST) Received: from smtpgw3.arbortext.com (IDENT:root@smtpgw3.arbortext.com [198.108.59.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TEnY822793 for ; Mon, 29 Oct 2001 06:49:35 -0800 (PST) Message-Id: <4.3.2.7.2.20011029083547.017b1098@172.27.10.30> X-Sender: pgrosso@172.27.10.30 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Oct 2001 08:40:15 -0600 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: determining ID-ness in XML In-Reply-To: <5.1.0.14.2.20011028204136.02072790@pop.intergate.ca> References: <3BDCC3C6.86A9FA0B@w3.org> <200110241818.OAA14482@markbaker.ca> Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on LORAX/DTW/ATI(Release 5.0.8 |June 18, 2001) at 10/29/2001 09:49:33 AM, Serialize by Router on LORAX/DTW/ATI(Release 5.0.8 |June 18, 2001) at 10/29/2001 09:49:33 AM, Serialize complete at 10/29/2001 09:49:33 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T9jAT01941 for ietf-xml-mime-bks; Mon, 29 Oct 2001 01:45:10 -0800 (PST) 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 f9T9j8801936 for ; Mon, 29 Oct 2001 01:45:08 -0800 (PST) X-VirusChecked: Checked Received: (qmail 16425 invoked from network); 29 Oct 2001 09:38:32 -0000 Received: from unknown (HELO nag.co.uk) (62.231.145.242) by server-6.tower-17.messagelabs.com with SMTP; 29 Oct 2001 09:38:32 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id JAA06094; Mon, 29 Oct 2001 09:44:40 GMT Date: Mon, 29 Oct 2001 09:44:40 GMT Message-Id: <200110290944.JAA11486@penguin.nag.co.uk> Received: by penguin.nag.co.uk (8.9.3) id JAA11486; Mon, 29 Oct 2001 09:44:40 GMT From: David Carlisle To: dan@dankohn.com CC: ietf-xml-mime@imc.org, xml-dev@lists.xml.org In-reply-to: <00e201c16012$9b69bb00$6401a8c0@skymoonventures.com> (dan@dankohn.com) Subject: Re: [xml-dev] Registration status References: <00e201c16012$9b69bb00$6401a8c0@skymoonventures.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T9K5G27286 for ietf-xml-mime-bks; Mon, 29 Oct 2001 01:20:05 -0800 (PST) Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T9K2827282 for ; Mon, 29 Oct 2001 01:20:02 -0800 (PST) Received: from fwd05.sul.t-online.de by mailout03.sul.t-online.de with smtp id 15y8Xe-0001jJ-0C; Mon, 29 Oct 2001 10:17:10 +0100 Received: from nobis (320029994702-0001@[62.155.169.208]) by fwd05.sul.t-online.com with smtp id 15y8XT-0pUXoWC; Mon, 29 Oct 2001 10:16:59 +0100 Received: from 192.168.115.1:1061 by KEN! DSL (0.0.0.0:25) with SMTP Mon Oct 29 10:10:31 2001 +0100 Message-Id: <001601c1605a$57bf1bf0$fe78a8c0@vobis> Reply-To: "Jens-H. Niggemeyer" From: jensnig@t-online.de (Jens-H. Niggemeyer) To: Subject: jensnig@localwhiz.com Date: Mon, 29 Oct 2001 10:16:04 +0100 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C16062.B74505A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Sender: 320029994702-0001@t-dialin.net Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 jensnig@localwhiz.com ------=_NextPart_000_0013_01C16062.B74505A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe jensnig@localwhiz.com
------=_NextPart_000_0013_01C16062.B74505A0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T4no700567 for ietf-xml-mime-bks; Sun, 28 Oct 2001 20:49:50 -0800 (PST) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T4nm800563 for ; Sun, 28 Oct 2001 20:49:48 -0800 (PST) Received: from rune.antarcti.ca (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id F279910A3C for ; Sun, 28 Oct 2001 20:49:44 -0800 (PST) Message-Id: <5.1.0.14.2.20011028204136.02072790@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 28 Oct 2001 20:49:36 -0800 To: ietf-xml-mime@imc.org From: Tim Bray Subject: Re: Preparing for XPointer In-Reply-To: <3BDCC3C6.86A9FA0B@w3.org> References: <200110241818.OAA14482@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T2nfP28362 for ietf-xml-mime-bks; Sun, 28 Oct 2001 18:49:41 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T2ne828357 for ; Sun, 28 Oct 2001 18:49:40 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA32570; Sun, 28 Oct 2001 21:49:42 -0500 Message-ID: <3BDCC3C6.86A9FA0B@w3.org> Date: Mon, 29 Oct 2001 03:49:42 +0100 From: Chris Lilley X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baker CC: ietf-xml-mime@imc.org Subject: Re: Preparing for XPointer References: <200110241818.OAA14482@markbaker.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: by above.proper.com (8.11.6/8.11.3) id f9T0oAM26190 for ietf-xml-mime-bks; Sun, 28 Oct 2001 16:50:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9T0o8826186 for ; Sun, 28 Oct 2001 16:50:08 -0800 (PST) Received: (qmail 26782 invoked by uid 0); 29 Oct 2001 00:50:06 -0000 Received: from 33-211.h.dial.o-tel-o.net (212.144.33.211) by mail.gmx.net (mp010-rz3) with SMTP; 29 Oct 2001 00:50:06 -0000 From: Bjoern Hoehrmann To: Chris Lilley Cc: ietf-xml-mime@imc.org Subject: Re: [xml-dev] Text/xml with omitted charset parameter Date: Mon, 29 Oct 2001 01:49:30 +0100 Organization: none Message-ID: <9j8ptt8mtfullt872ornc3okje4ptggl4u@4ax.com> References: <3BDC9829.C7B96466@w3.org> In-Reply-To: <3BDC9829.C7B96466@w3.org> X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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: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/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T0gZd26060 for ietf-xml-mime-bks; Sun, 28 Oct 2001 16:42:35 -0800 (PST) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T0gY826056 for ; Sun, 28 Oct 2001 16:42:34 -0800 (PST) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15y0Vg-0003hK-00; Mon, 29 Oct 2001 00:42:36 +0000 Received: from [64.163.212.138] (helo=dan3480) by dfw-mmp2.email.verio.net with asmtp (110190536) id 15y0Vi-0006jk-00; Mon, 29 Oct 2001 00:42:38 +0000 From: "Dan Kohn" To: "'David Carlisle'" Cc: , Subject: RE: [xml-dev] Registration status Date: Sun, 28 Oct 2001 16:42:36 -0800 Message-ID: <00e201c16012$9b69bb00$6401a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 In-Reply-To: <200110290036.AAA10509@penguin.nag.co.uk> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Essays announced on -----Original Message----- From: David Carlisle [mailto:davidc@nag.co.uk] Sent: Sunday, October 28, 2001 16:36 To: dan@dankohn.com Cc: ietf-xml-mime@imc.org; xml-dev@lists.xml.org 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. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9T0acg25954 for ietf-xml-mime-bks; Sun, 28 Oct 2001 16:36:38 -0800 (PST) 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 f9T0ab825950 for ; Sun, 28 Oct 2001 16:36:37 -0800 (PST) X-VirusChecked: Checked Received: (qmail 15165 invoked from network); 29 Oct 2001 00:30:22 -0000 Received: from unknown (HELO nag.co.uk) (62.231.145.242) by server-5.tower-17.messagelabs.com with SMTP; 29 Oct 2001 00:30:22 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id AAA02527; Mon, 29 Oct 2001 00:36:19 GMT Date: Mon, 29 Oct 2001 00:36:16 GMT Message-Id: <200110290036.AAA10509@penguin.nag.co.uk> Received: by penguin.nag.co.uk (8.9.3) id AAA10509; Mon, 29 Oct 2001 00:36:16 GMT From: David Carlisle To: dan@dankohn.com CC: ietf-xml-mime@imc.org, xml-dev@lists.xml.org In-reply-to: <00c001c16001$9ed4e230$6401a8c0@skymoonventures.com> (dan@dankohn.com) Subject: Re: [xml-dev] Registration status References: <00c001c16001$9ed4e230$6401a8c0@skymoonventures.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9SNhbD25066 for ietf-xml-mime-bks; Sun, 28 Oct 2001 15:43:37 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9SNha825062 for ; Sun, 28 Oct 2001 15:43:36 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA17281; Sun, 28 Oct 2001 18:43:37 -0500 Message-ID: <3BDC9829.C7B96466@w3.org> Date: Mon, 29 Oct 2001 00:43:37 +0100 From: Chris Lilley X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Elliotte Rusty Harold CC: ietf-xml-mime@imc.org Subject: Re: [xml-dev] Text/xml with omitted charset parameter References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9SMewG24132 for ietf-xml-mime-bks; Sun, 28 Oct 2001 14:40:58 -0800 (PST) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9SMev824128 for ; Sun, 28 Oct 2001 14:40:57 -0800 (PST) Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15xybx-0005cS-00; Sun, 28 Oct 2001 22:40:57 +0000 Received: from [64.163.212.138] (helo=dan3480) by dfw-mmp1.email.verio.net with asmtp (110190536) id 15xybx-0002Xz-00; Sun, 28 Oct 2001 22:40:57 +0000 From: "Dan Kohn" To: "'David Carlisle'" , Cc: , , Subject: RE: [xml-dev] Registration status Date: Sun, 28 Oct 2001 14:40:59 -0800 Message-ID: <00c001c16001$9ed4e230$6401a8c0@skymoonventures.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000 In-Reply-To: <200110282214.WAA10291@penguin.nag.co.uk> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Essays announced on -----Original Message----- From: owner-ietf-xml-mime@mail.imc.org [mailto:owner-ietf-xml-mime@mail.imc.org] On Behalf Of David Carlisle Sent: Sunday, October 28, 2001 14:15 To: distobj@acm.org Cc: elharo@metalab.unc.edu; ietf-xml-mime@imc.org; xml-dev@lists.xml.org 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. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9SMF9323723 for ietf-xml-mime-bks; Sun, 28 Oct 2001 14:15:09 -0800 (PST) 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 f9SMF7823718 for ; Sun, 28 Oct 2001 14:15:08 -0800 (PST) X-VirusChecked: Checked Received: (qmail 5728 invoked from network); 28 Oct 2001 22:08:36 -0000 Received: from unknown (HELO nag.co.uk) (62.231.145.242) by server-8.tower-17.messagelabs.com with SMTP; 28 Oct 2001 22:08:36 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id WAA01943; Sun, 28 Oct 2001 22:14:51 GMT Date: Sun, 28 Oct 2001 22:14:48 GMT Message-Id: <200110282214.WAA10291@penguin.nag.co.uk> Received: by penguin.nag.co.uk (8.9.3) id WAA10291; Sun, 28 Oct 2001 22:14:48 GMT From: David Carlisle To: distobj@acm.org CC: elharo@metalab.unc.edu, ietf-xml-mime@imc.org, xml-dev@lists.xml.org In-reply-to: <200110282150.QAA07129@markbaker.ca> (message from Mark Baker on Sun, 28 Oct 2001 16:50:28 -0500 (EST)) Subject: Re: [xml-dev] Registration status References: <200110282150.QAA07129@markbaker.ca> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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. Received: by above.proper.com (8.11.6/8.11.3) id f9SLxp623330 for ietf-xml-mime-bks; Sun, 28 Oct 2001 13:59:51 -0800 (PST) Received: from server-3.tower-17.messagelabs.com (mail17.messagelabs.com [62.231.131.67]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9SLxo823326 for ; Sun, 28 Oct 2001 13:59:50 -0800 (PST) X-VirusChecked: Checked Received: (qmail 30378 invoked from network); 28 Oct 2001 21:54:02 -0000 Received: from unknown (HELO nag.co.uk) (62.231.145.242) by server-3.tower-17.messagelabs.com with SMTP; 28 Oct 2001 21:54:02 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id VAA01831 for ; Sun, 28 Oct 2001 21:59:32 GMT Date: Sun, 28 Oct 2001 21:59:30 GMT Message-Id: <200110282159.VAA10274@penguin.nag.co.uk> Received: by penguin.nag.co.uk (8.9.3) id VAA10274; Sun, 28 Oct 2001 21:59:30 GMT From: David Carlisle To: ietf-xml-mime@imc.org Subject: Re: [xml-dev] Registration status Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [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 ; 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:root@penguin.nag.co.uk >[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: <200110281752.RAA10002@penguin.nag.co.uk> >Received: by penguin.nag.co.uk (8.9.3) id RAA10002; Sun, 28 Oct 2001 >17:52:38 GMT >From: David Carlisle >To: elharo@metalab.unc.edu >CC: ietf-xml-mime@imc.org, xml-dev@lists.xml.org >In-reply-to: <3BDB716C.3020208@metalab.unc.edu> (message from Elliotte Rusty > Harold on Sat, 27 Oct 2001 19:46:04 -0700) >Subject: Re: [xml-dev] Registration status >References: <3BDB716C.3020208@metalab.unc.edu> > > >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. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9SLqO423237 for ietf-xml-mime-bks; Sun, 28 Oct 2001 13:52:24 -0800 (PST) Received: from ic-unix.ic.utoronto.ca (ic-unix.ic.utoronto.ca [142.150.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9SLqN823232 for ; Sun, 28 Oct 2001 13:52:23 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id QAA26486 for ; Sun, 28 Oct 2001 16:44:56 -0500 (EST) Date: Sun, 28 Oct 2001 16:44:56 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: ietf-xml-mime@imc.org Subject: Re: [xml-dev] Registration status (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ---------- Forwarded message ---------- >cc: elharo@metalab.unc.edu, ietf-xml-mime@imc.org, xml-dev@lists.xml.org > > >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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9SLkZM23154 for ietf-xml-mime-bks; Sun, 28 Oct 2001 13:46:35 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9SLkY823150 for ; Sun, 28 Oct 2001 13:46:34 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id QAA07129; Sun, 28 Oct 2001 16:50:28 -0500 Message-Id: <200110282150.QAA07129@markbaker.ca> Subject: Re: [xml-dev] Registration status To: davidc@nag.co.uk (David Carlisle) Date: Sun, 28 Oct 2001 16:50:28 -0500 (EST) Cc: elharo@metalab.unc.edu, ietf-xml-mime@imc.org, xml-dev@lists.xml.org In-Reply-To: <200110281752.RAA10002@penguin.nag.co.uk> from "David Carlisle" at Oct 28, 2001 05:52:38 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 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. mbaker@planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id f9SIIfN18043 for ietf-xml-mime-bks; Sun, 28 Oct 2001 10:18:41 -0800 (PST) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9SIId818039 for ; Sun, 28 Oct 2001 10:18:40 -0800 (PST) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA25873; Sun, 28 Oct 2001 13:18:40 -0500 Message-ID: <3BDC4C00.9D6B0C10@w3.org> Date: Sun, 28 Oct 2001 19:18:40 +0100 From: Chris Lilley X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Elliotte Rusty Harold CC: ietf-xml-mime@imc.org, xml-dev Subject: Re: Registration status References: <3BDB716C.3020208@metalab.unc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9S15TD13264 for ietf-xml-mime-bks; Sat, 27 Oct 2001 18:05:29 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9S15T813260 for ; Sat, 27 Oct 2001 18:05:29 -0700 (PDT) Received: (qmail 84689 invoked from network); 28 Oct 2001 01:05:32 -0000 Received: from unknown (HELO ?192.168.254.4?) ([216.254.85.72]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Oct 2001 01:05:32 -0000 Mime-Version: 1.0 X-Sender: elharo@luna.metalab.unc.edu Message-Id: In-Reply-To: References: Date: Sat, 27 Oct 2001 21:02:06 -0400 To: xml-dev@lists.xml.org From: Elliotte Rusty Harold Subject: Re: [xml-dev] Text/xml with omitted charset parameter Cc: ietf-xml-mime@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 | elharo@metalab.unc.edu | 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/ | +----------------------------------+---------------------------------+ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9S0wta13188 for ietf-xml-mime-bks; Sat, 27 Oct 2001 17:58:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9S0ws813184 for ; Sat, 27 Oct 2001 17:58:54 -0700 (PDT) Received: (qmail 874 invoked by uid 0); 28 Oct 2001 00:58:51 -0000 Received: from 33-45.h.dial.o-tel-o.net (212.144.33.45) by mail.gmx.net (mp011-rz3) with SMTP; 28 Oct 2001 00:58:51 -0000 From: Bjoern Hoehrmann To: Elliotte Rusty Harold Cc: ietf-xml-mime@imc.org, xml-dev Subject: Re: Registration status Date: Sun, 28 Oct 2001 02:58:14 +0200 Organization: none Message-ID: References: <3BDB716C.3020208@metalab.unc.edu> In-Reply-To: <3BDB716C.3020208@metalab.unc.edu> X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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 svg-developer@yahoogroups.com 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: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/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9RNs3m12778 for ietf-xml-mime-bks; Sat, 27 Oct 2001 16:54:03 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9RNs2812774 for ; Sat, 27 Oct 2001 16:54:02 -0700 (PDT) Received: (qmail 81287 invoked from network); 27 Oct 2001 23:54:05 -0000 Received: from unknown (HELO metalab.unc.edu) ([216.254.85.72]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 23:54:05 -0000 Message-ID: <3BDB716C.3020208@metalab.unc.edu> Date: Sat, 27 Oct 2001 19:46:04 -0700 From: Elliotte Rusty Harold User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-xml-mime@imc.org CC: xml-dev Subject: Registration status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 | elharo@metalab.unc.edu | 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/ | +----------------------------------+---------------------------------+ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9RKTIP10630 for ietf-xml-mime-bks; Sat, 27 Oct 2001 13:29:18 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9RKTG810626 for ; Sat, 27 Oct 2001 13:29:16 -0700 (PDT) Received: from rune.antarcti.ca (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 399E010A23; Sat, 27 Oct 2001 13:29:08 -0700 (PDT) Message-Id: <5.1.0.14.2.20011027103508.020e2080@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 27 Oct 2001 10:40:16 -0700 To: xml-dev@lists.xml.org, ietf-xml-mime@imc.org From: Tim Bray Subject: Re: [xml-dev] Text/xml with omitted charset parameter In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9RA1Hr09562 for ietf-xml-mime-bks; Sat, 27 Oct 2001 03:01:17 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9RA1G809558 for ; Sat, 27 Oct 2001 03:01:16 -0700 (PDT) Received: (qmail 70012 invoked from network); 27 Oct 2001 10:01:05 -0000 Received: from unknown (HELO ?192.168.254.4?) ([216.254.85.72]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Oct 2001 10:01:05 -0000 Mime-Version: 1.0 X-Sender: elharo@luna.metalab.unc.edu Message-Id: In-Reply-To: References: Date: Sat, 27 Oct 2001 04:54:56 -0400 To: xml-dev@lists.xml.org From: Elliotte Rusty Harold Subject: Re: [xml-dev] Text/xml with omitted charset parameter Cc: ietf-xml-mime@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 | elharo@metalab.unc.edu | 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/ | +----------------------------------+---------------------------------+ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9QJo1K00159 for ietf-xml-mime-bks; Fri, 26 Oct 2001 12:50:01 -0700 (PDT) Received: from smtp.hq.allegis.com (smtp.allegis.com [199.242.245.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QJo1800155 for ; Fri, 26 Oct 2001 12:50:01 -0700 (PDT) Received: from mailhost.hq.allegis.com (mailhost.hq.allegis.com [172.16.0.23]) by smtp.hq.allegis.com (8.9.3/8.9.3) with ESMTP id MAA12699; Fri, 26 Oct 2001 12:49:56 -0700 Received: by mailhost.hq.allegis.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 12:45:42 -0700 Message-ID: <753B28EF1C2DD411AF1C00B0D0202CB502480BFE@mailhost.hq.allegis.com> From: Michael Brennan To: "'Bjoern Hoehrmann'" Cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: RE: [xml-dev] Text/xml with omitted charset parameter Date: Fri, 26 Oct 2001 12:45:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > 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. Received: by above.proper.com (8.11.6/8.11.3) id f9Q2gew10137 for ietf-xml-mime-bks; Thu, 25 Oct 2001 19:42:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9Q2gc810133 for ; Thu, 25 Oct 2001 19:42:38 -0700 (PDT) Received: (qmail 22243 invoked by uid 0); 26 Oct 2001 02:42:36 -0000 Received: from pd903b33e.dip.t-dialin.net (217.3.179.62) by mail.gmx.net (mp007-rz3) with SMTP; 26 Oct 2001 02:42:36 -0000 From: Bjoern Hoehrmann To: Michael Brennan Cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Text/xml with omitted charset parameter Date: Fri, 26 Oct 2001 04:42:01 +0200 Organization: none Message-ID: References: <753B28EF1C2DD411AF1C00B0D0202CB502480BF5@mailhost.hq.allegis.com> In-Reply-To: <753B28EF1C2DD411AF1C00B0D0202CB502480BF5@mailhost.hq.allegis.com> X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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: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/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9Q17hC08390 for ietf-xml-mime-bks; Thu, 25 Oct 2001 18:07:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9Q17g808385 for ; Thu, 25 Oct 2001 18:07:42 -0700 (PDT) Received: (qmail 31183 invoked by uid 0); 26 Oct 2001 01:07:39 -0000 Received: from pd903ba34.dip.t-dialin.net (217.3.186.52) by mail.gmx.net (mp005-rz3) with SMTP; 26 Oct 2001 01:07:39 -0000 From: Bjoern Hoehrmann To: ietf-xml-mime@imc.org Cc: xml-dev@lists.xml.org Subject: Text/xml with omitted charset parameter Date: Fri, 26 Oct 2001 03:07:04 +0200 Organization: none Message-ID: X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Quoting RFC 3023, section 8.5: | 8.5 Text/xml with Omitted Charset | | Content-type: text/xml | | {BOM} | | or | | {BOM} | | 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: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/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9OK0GP13089 for ietf-xml-mime-bks; Wed, 24 Oct 2001 13:00:16 -0700 (PDT) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OK0D813079 for ; Wed, 24 Oct 2001 13:00:14 -0700 (PDT) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id f9OK0AU15581; Wed, 24 Oct 2001 16:00:10 -0400 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Preparing for XPointer From: "Simon St.Laurent" To: Mark Baker Cc: ietf-xml-mime@imc.org In-Reply-To: <200110241818.OAA14482@markbaker.ca> References: <200110241818.OAA14482@markbaker.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.15 (Preview Release) Date: 24 Oct 2001 16:03:12 -0400 Message-Id: <1003953793.17219.0.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9OJk3e12756 for ietf-xml-mime-bks; Wed, 24 Oct 2001 12:46:03 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OJk2812751 for ; Wed, 24 Oct 2001 12:46:02 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id PAA15206; Wed, 24 Oct 2001 15:49:42 -0400 Message-Id: <200110241949.PAA15206@markbaker.ca> Subject: Re: Preparing for XPointer To: derhoermi@gmx.net (Bjoern Hoehrmann) Date: Wed, 24 Oct 2001 15:49:41 -0400 (EDT) Cc: ietf-xml-mime@imc.org In-Reply-To: from "Bjoern Hoehrmann" at Oct 24, 2001 09:24:26 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > * 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. mbaker@planetfred.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9OJP6Y12366 for ietf-xml-mime-bks; Wed, 24 Oct 2001 12:25:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9OJP5812362 for ; Wed, 24 Oct 2001 12:25:05 -0700 (PDT) Received: (qmail 21372 invoked by uid 0); 24 Oct 2001 19:25:01 -0000 Received: from pd903b37e.dip.t-dialin.net (217.3.179.126) by mail.gmx.net (mp007-rz3) with SMTP; 24 Oct 2001 19:25:01 -0000 From: Bjoern Hoehrmann To: Mark Baker Cc: ietf-xml-mime@imc.org Subject: Re: Preparing for XPointer Date: Wed, 24 Oct 2001 21:24:26 +0200 Organization: none Message-ID: References: <200110241818.OAA14482@markbaker.ca> In-Reply-To: <200110241818.OAA14482@markbaker.ca> X-Mailer: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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: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/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9OIEnN09368 for ietf-xml-mime-bks; Wed, 24 Oct 2001 11:14:49 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OIEm809361 for ; Wed, 24 Oct 2001 11:14:48 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id OAA14482 for ietf-xml-mime@imc.org; Wed, 24 Oct 2001 14:18:29 -0400 Message-Id: <200110241818.OAA14482@markbaker.ca> Subject: Preparing for XPointer To: ietf-xml-mime@imc.org Date: Wed, 24 Oct 2001 14:18:29 -0400 (EDT) From: Mark Baker X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. mbaker@planetfred.com