From: dan at dankohn.com (Dan Kohn) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications Message-ID: <138AA78F80DCE84B8EE424399FFBF9C9195DC2@exchange.ad.skymv.com> >> As I have some programming background I think >> application/xhtml|xml would have been much better and the pipe was >> available in addition to the plus sign. For historical curiosity, I'll mention that as a co-author of RFC 3023, I was in favor of using the pipe | (e.g., application/xhtml|xml, which was used in an earlier draft), but I was convinced by my co-authors that it could be too easily confused with capital I and lowercase l in many fonts. I suspect it didn't really matter, and the delimiter is in any event now firmly established as +. - dan -- Dan Kohn >From dan@dankohn.com Mon Apr 21 17:38:32 2003 From: dan at dankohn.com (Dan Kohn) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications Message-ID: <138AA78F80DCE84B8EE424399FFBF9C9195DC2@exchange.ad.skymv.com> >> As I have some programming background I think >> application/xhtml|xml would have been much better and the pipe was >> available in addition to the plus sign. For historical curiosity, I'll mention that as a co-author of RFC 3023, I was in favor of using the pipe | (e.g., application/xhtml|xml, which was used in an earlier draft), but I was convinced by my co-authors that it could be too easily confused with capital I and lowercase l in many fonts. I suspect it didn't really matter, and the delimiter is in any event now firmly established as +. - dan -- Dan Kohn From: dan at dankohn.com (Dan Kohn) Date: Mon Apr 21 17:39:11 2003 Subject: XHTML, XML, fancy text, and applications Message-ID: <138AA78F80DCE84B8EE424399FFBF9C9195DC2@exchange.ad.skymv.com> >> As I have some programming background I think >> application/xhtml|xml would have been much better and the pipe was >> available in addition to the plus sign. For historical curiosity, I'll mention that as a co-author of RFC 3023, I was in favor of using the pipe | (e.g., application/xhtml|xml, which was used in an earlier draft), but I was convinced by my co-authors that it could be too easily confused with capital I and lowercase l in many fonts. I suspect it didn't really matter, and the delimiter is in any event now firmly established as +. - dan -- Dan Kohn >From dan@dankohn.com Mon Apr 21 09:38:32 2003 From: dan at dankohn.com (Dan Kohn) Date: Mon Apr 21 23:31:14 2003 Subject: XHTML, XML, fancy text, and applications Message-ID: <138AA78F80DCE84B8EE424399FFBF9C9195DC2@exchange.ad.skymv.com> >> As I have some programming background I think >> application/xhtml|xml would have been much better and the pipe was >> available in addition to the plus sign. For historical curiosity, I'll mention that as a co-author of RFC 3023, I was in favor of using the pipe | (e.g., application/xhtml|xml, which was used in an earlier draft), but I was convinced by my co-authors that it could be too easily confused with capital I and lowercase l in many fonts. I suspect it didn't really matter, and the delimiter is in any event now firmly established as +. - dan -- Dan Kohn From: ylafon at w3.org (Yves Lafon) Date: Tue Apr 22 22:56:09 2003 Subject: Please review ietf-draft of the "application/soap+xml" media type Message-ID: This email serves to instantiate the two weeks discussion period on "ietf-types@iana.org" of the ietf-draft describing the "application/soap+xml" media type registration. You can find the draft at http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-02.txt Thank you. -- Yves Lafon - W3C "Baroula que barouleras, au ti?u toujou t'entourneras." -------------- next part -------------- Internet-Draft Mark Baker Expires: October, 2003 Independent Mark Nottingham BEA Systems April 14, 2003 The "application/soap+xml" media type draft-baker-soap-media-reg-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Feedback or discussion about this draft should be directed to the XML Protocol Working Group public mailing list, xml-dist-app@w3.org with archives at http://lists.w3.org/Archives/Public/xml-dist-app/ Abstract This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML. 1. Introduction SOAP version 1.2 (SOAP) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols. This specification defines the media type "application/soap+xml" which can be used to identify SOAP messages serialized with XML 1.0 carried in MIME or MIME like protocols that support the concept of media types for which a SOAP binding has been defined. 2. Registration The registration form can be found in Appendix A of the "SOAP 1.2 Part 2: Adjuncts" [SOAP12P2] specification. 3. Authors' Addresses Mark A. Baker Independent 37 Charles St. Ottawa, Ontario, CANADA. K1M 1R3 tel:+1-613-286-4390 mailto:distobj@acm.org Mark Nottingham BEA Systems Level 15, 235 Montgomery Street San Francisco, CA, US. 94104 mailto:mnot@pobox.com 4. References [SOAP12P2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Candidate Recommendation (work in progress), December 2002. Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, JJ., Nielsen, H. . >From ewexler@stickdog.com Sat Apr 12 02:38:54 2003 From: ewexler at stickdog.com (Etan Wexler) Date: Tue Jan 3 16:22:34 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <3E94185F.10003@cc.jyu.fi> Message-ID: Mikko Rantalainen wrote to on 9 April 2003 in "Re: XHTML2 MIME type" (): > [This is getting a bit offtopic and I'm not really expecting any > replies. I'll post some thoughts to help future archive diggers.] I'm steering the discussion into the MIME media types list, . Please send public replies there. > OK. This is the first time I actually viewed RFC 3023 and I want to say > that I consider "+xml" extension as an ugly hack. I consider it an elegant solution. Our difference leads me to conclude that this is at least partly a matter of taste. De gustibus non disputandum. > I'm still wondering why they choose > to use "+" as a separator if the meaning is "this file can be considered > as something OR xml". I would see it as "This resource is of such-and-such type AND it is XML in terms of syntax." > When I first time saw application/xhtml+xml I > immediatly thought that it meant it's an xhtml file with possible > additional namespaces. While I affirm the principle that MIME media type names should be as clear as is possible within the limited character repertoire and some reasonable length, we have IANA registrations and Requests For Comments that define each type. Those documents are meant for reading, not for ignoring. > As I have some programming background I think > application/xhtml|xml would have been much better and the pipe was > available in addition to the plus sign. As I know that non-programmer lay people encounter MIME media type names with some frequency on the Web (by "Web" I'm including mail systems), I have to say that the pipe character ("|", vertical line, U+007C) is too devoid of well-known semantics. In my experience in the English-speaking United States, if there is any character that commonly denotes alternatives, it is the slash ("/", solidus, U+002F). (Perhaps, in that case, I should have written slash/solidus.) The slash is reserved and will not find its way into a MIME media subtype name. > After reading the references you provided I still feel that we need a > new top level mime type. We have various file types that are basically > text but not plain text. Right, and those should be subtypes of "text" if they can reasonably be treated as "text/plain", or subtypes of "application" if they contain non-textual markup. > If the reason for not having another top level MIME type for xml/* is > that we want to specify TYPE instead of SYNTAX then the text/* shouldn't > be considered as plain text syntax either and it should be used for all > file types that mostly contain text. I think that the principle in effect is that treatment as "text/plain" has to be a reasonable fallback for any "text" subtype. What constitutes reasonable is a matter for debate. I suspect that most people could not make sense of Postscript source code (hence "application/postscript"), even though it is textual. HTML source code, on the other hand, is likely to contain passages of readable text (hence "text/html"), even if it leaves the reader wondering what all the symbols mean. > I think the application/* top level type shouldn't be used for XHTML 2 > just because one needs an application to easily read the content. My understanding is that the MIME media type name "application" describes the content itself, not the necessary processing software. It's like "This resource is an application of some sort", not like "Start an application to handle this resource". > Following the same logic we should move all of image/*, video/* and > audio/* types to application/* because you cannot view any of those > without an application either. Again, the term "application" describes the resource, not the handler. > Perhaps application/* should be renamed to misc/* or other/*? That sounds like a terrible idea, given the installed base of software that understands and expects the "application" name. -- Etan Wexler: stuffed but not satiated, damn it. From: ylafon at w3.org (Yves Lafon) Date: Tue Jan 3 16:22:35 2006 Subject: Please review ietf-draft of the "application/soap+xml" media type Message-ID: This email serves to instantiate the two weeks discussion period on "ietf-types@iana.org" of the ietf-draft describing the "application/soap+xml" media type registration. You can find the draft at http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-02.txt Thank you. -- Yves Lafon - W3C "Baroula que barouleras, au ti?u toujou t'entourneras." -------------- next part -------------- Internet-Draft Mark Baker Expires: October, 2003 Independent Mark Nottingham BEA Systems April 14, 2003 The "application/soap+xml" media type draft-baker-soap-media-reg-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Feedback or discussion about this draft should be directed to the XML Protocol Working Group public mailing list, xml-dist-app@w3.org with archives at http://lists.w3.org/Archives/Public/xml-dist-app/ Abstract This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML. 1. Introduction SOAP version 1.2 (SOAP) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols. This specification defines the media type "application/soap+xml" which can be used to identify SOAP messages serialized with XML 1.0 carried in MIME or MIME like protocols that support the concept of media types for which a SOAP binding has been defined. 2. Registration The registration form can be found in Appendix A of the "SOAP 1.2 Part 2: Adjuncts" [SOAP12P2] specification. 3. Authors' Addresses Mark A. Baker Independent 37 Charles St. Ottawa, Ontario, CANADA. K1M 1R3 tel:+1-613-286-4390 mailto:distobj@acm.org Mark Nottingham BEA Systems Level 15, 235 Montgomery Street San Francisco, CA, US. 94104 mailto:mnot@pobox.com 4. References [SOAP12P2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Candidate Recommendation (work in progress), December 2002. Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, JJ., Nielsen, H. . From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: Message-ID: <003301c302d1$17400d80$57432099@MASINTERPAD> The mailing list that produced RFC 3023 is archived at http://www.imc.org/ietf-xml-mime/mail-archive/maillist.html for anyone who wants to revisit the discussions that led to the "+xml" recommendation. The list (ietf-xml-mime@imc.org) is still open, and there's likely to be an update of RFC 3023 to account for XLink. From: LMM at acm.org (Larry Masinter) Date: Mon Apr 14 23:59:26 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: Message-ID: <003301c302d1$17400d80$57432099@MASINTERPAD> The mailing list that produced RFC 3023 is archived at http://www.imc.org/ietf-xml-mime/mail-archive/maillist.html for anyone who wants to revisit the discussions that led to the "+xml" recommendation. The list (ietf-xml-mime@imc.org) is still open, and there's likely to be an update of RFC 3023 to account for XLink. From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Sun Apr 13 20:13:25 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <1050186558.4893.28.camel@felicia> References: <1050186558.4893.28.camel@felicia> Message-ID: <20030414030809.B816.MURATA@hokkaido.email.ne.jp> On Sun, 13 Apr 2003 14:12:17 +0200 Linus Walleij wrote: > This discussion is new on this list and sound confusing to me. It would > be nice to have a briefing on the background facts. I believe that Appendix A of RFC 3023 answers your questions. I quote one paragraph, but please read that appendix entirely. > Sniffing XML also isn't as simple as it might seem. DOCTYPE > declarations aren't required, and they can appear fairly deep into a > document under certain unpreventable circumstances. (E.g., the XML > declaration, comments, and processing instructions can occupy space > before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't > completely reliable, thanks to a variety of issues involving default > values for namespaces within external DTDs and overrides inside the > internal DTD. Finally, the variety in potential character encodings > (something XML provides tools to deal with), also makes reliable > sniffing less likely. -- MURATA Makoto From: triad at df.lth.se (Linus Walleij) Date: Sun Apr 13 21:21:51 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <4.2.0.58.J.20030413125758.063a0f10@localhost> References: <4.2.0.58.J.20030413125758.063a0f10@localhost> Message-ID: <1050261661.15557.23.camel@felicia> Oh, well I get the point after reviewing the docs. Well if W3 have themselves engineered XML to be only optionally and under certain circumstances competent to describe itself, the good old IETF transport types will have to keep doing the job I guess. Just keep the types coming then, I don't mind... Linus From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <4.2.0.58.J.20030413125758.063a0f10@localhost> References: <4.2.0.58.J.20030413125758.063a0f10@localhost> Message-ID: <1050261661.15557.23.camel@felicia> Oh, well I get the point after reviewing the docs. Well if W3 have themselves engineered XML to be only optionally and under certain circumstances competent to describe itself, the good old IETF transport types will have to keep doing the job I guess. Just keep the types coming then, I don't mind... Linus From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <1050186558.4893.28.camel@felicia> References: <1050186558.4893.28.camel@felicia> Message-ID: <20030414030809.B816.MURATA@hokkaido.email.ne.jp> On Sun, 13 Apr 2003 14:12:17 +0200 Linus Walleij wrote: > This discussion is new on this list and sound confusing to me. It would > be nice to have a briefing on the background facts. I believe that Appendix A of RFC 3023 answers your questions. I quote one paragraph, but please read that appendix entirely. > Sniffing XML also isn't as simple as it might seem. DOCTYPE > declarations aren't required, and they can appear fairly deep into a > document under certain unpreventable circumstances. (E.g., the XML > declaration, comments, and processing instructions can occupy space > before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't > completely reliable, thanks to a variety of issues involving default > values for namespaces within external DTDs and overrides inside the > internal DTD. Finally, the variety in potential character encodings > (something XML provides tools to deal with), also makes reliable > sniffing less likely. -- MURATA Makoto From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <1050186558.4893.28.camel@felicia> References: Message-ID: <4.2.0.58.J.20030413125758.063a0f10@localhost> Hello Ethan, Linus, others, At 14:12 03/04/13 +0200, Linus Walleij wrote: >This discussion is new on this list and sound confusing to me. It would >be nice to have a briefing on the background facts. For background/facts, see 1) RFC 3023 itself, in particular Appendix A (http://www.ietf.org/rfc/rfc3023.txt) 2) The archives of the ietf-xml-mime mailing list, at http://www.imc.org/ietf-xml-mime/mail-archive/maillist.html Please come back to discuss here after you have reviewed these resources. Regards, Martin. >For example, I want to know where the *existing* and *used* transport >types application/xml text/xml fits into this, and why it shouldn't be >used for XHTML like for all other XML derivates. If the browser >recognize that this XML file belongs to a certain namespace and should >be rendered in a certain way (xhtml-wise) that is in my humble opinion >not a *transport* problem. > > > I would see it as "This resource is of such-and-such type AND it is XML in > > terms of syntax." > >= content type text/xml, and the first row of that XML-compliant file: > >"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd"> > >will tell that it is of such-and-such XML derivative type. This is thus >not a transport issue. The transport types are designed to be quite >general. A binary file has no standard for deciphering it's contents >(well with the exception of say Quicktime and such non-IETF de facto >standards) why it has to be carried in it's own transport type. > >text/xml and application/xml are reserved for XML derivatives. These >additionally have clear syntax for describing their context i.e. > so they need no additional transport typing. To add it >anyway would be unnecessary duplication of information. > > > I have > > to say that the pipe character ("|", vertical line, U+007C) is too > devoid of > > well-known semantics. > >This is a technical standard, and the pipe sign has been a part of the >Backuss-Naur form denoting alternatives since the 1960s. It is nowadays >usually used in the Extended Backus-Naur form for regular expressions. >The Backus-Naur was developed heavily inspired by Noam Chomskys language >hierarchy and formalisms for grammar introduced with his book "Syntactic >Structures" in the 1950s. Chomsky didn't have pipes, but both BNF and >EBNF has. This is the reason why it was in the DTDs, and why it is part >of most document description syntaxes. That is: it is not devoid of >well-known semantics. > >This might be a totally off-topic reply in regards to this discussion, >but I could not accept that statemant as it stood. > > > Right, and those should be subtypes of "text" if they can reasonably be > > treated as "text/plain", or subtypes of "application" if they contain > > non-textual markup. > >application/xml and text/xml both already exist. What is wrong with >them? > >-- >Linus Walleij From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <1050186558.4893.28.camel@felicia> References: Message-ID: <4.2.0.58.J.20030413125758.063a0f10@localhost> Hello Ethan, Linus, others, At 14:12 03/04/13 +0200, Linus Walleij wrote: >This discussion is new on this list and sound confusing to me. It would >be nice to have a briefing on the background facts. For background/facts, see 1) RFC 3023 itself, in particular Appendix A (http://www.ietf.org/rfc/rfc3023.txt) 2) The archives of the ietf-xml-mime mailing list, at http://www.imc.org/ietf-xml-mime/mail-archive/maillist.html Please come back to discuss here after you have reviewed these resources. Regards, Martin. >For example, I want to know where the *existing* and *used* transport >types application/xml text/xml fits into this, and why it shouldn't be >used for XHTML like for all other XML derivates. If the browser >recognize that this XML file belongs to a certain namespace and should >be rendered in a certain way (xhtml-wise) that is in my humble opinion >not a *transport* problem. > > > I would see it as "This resource is of such-and-such type AND it is XML in > > terms of syntax." > >= content type text/xml, and the first row of that XML-compliant file: > >"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd"> > >will tell that it is of such-and-such XML derivative type. This is thus >not a transport issue. The transport types are designed to be quite >general. A binary file has no standard for deciphering it's contents >(well with the exception of say Quicktime and such non-IETF de facto >standards) why it has to be carried in it's own transport type. > >text/xml and application/xml are reserved for XML derivatives. These >additionally have clear syntax for describing their context i.e. > so they need no additional transport typing. To add it >anyway would be unnecessary duplication of information. > > > I have > > to say that the pipe character ("|", vertical line, U+007C) is too > devoid of > > well-known semantics. > >This is a technical standard, and the pipe sign has been a part of the >Backuss-Naur form denoting alternatives since the 1960s. It is nowadays >usually used in the Extended Backus-Naur form for regular expressions. >The Backus-Naur was developed heavily inspired by Noam Chomskys language >hierarchy and formalisms for grammar introduced with his book "Syntactic >Structures" in the 1950s. Chomsky didn't have pipes, but both BNF and >EBNF has. This is the reason why it was in the DTDs, and why it is part >of most document description syntaxes. That is: it is not devoid of >well-known semantics. > >This might be a totally off-topic reply in regards to this discussion, >but I could not accept that statemant as it stood. > > > Right, and those should be subtypes of "text" if they can reasonably be > > treated as "text/plain", or subtypes of "application" if they contain > > non-textual markup. > >application/xml and text/xml both already exist. What is wrong with >them? > >-- >Linus Walleij From: triad at df.lth.se (Linus Walleij) Date: Sun Apr 13 14:13:15 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: References: Message-ID: <1050186558.4893.28.camel@felicia> This discussion is new on this list and sound confusing to me. It would be nice to have a briefing on the background facts. For example, I want to know where the *existing* and *used* transport types application/xml text/xml fits into this, and why it shouldn't be used for XHTML like for all other XML derivates. If the browser recognize that this XML file belongs to a certain namespace and should be rendered in a certain way (xhtml-wise) that is in my humble opinion not a *transport* problem. > I would see it as "This resource is of such-and-such type AND it is XML in > terms of syntax." = content type text/xml, and the first row of that XML-compliant file: will tell that it is of such-and-such XML derivative type. This is thus not a transport issue. The transport types are designed to be quite general. A binary file has no standard for deciphering it's contents (well with the exception of say Quicktime and such non-IETF de facto standards) why it has to be carried in it's own transport type. text/xml and application/xml are reserved for XML derivatives. These additionally have clear syntax for describing their context i.e. so they need no additional transport typing. To add it anyway would be unnecessary duplication of information. > I have > to say that the pipe character ("|", vertical line, U+007C) is too devoid of > well-known semantics. This is a technical standard, and the pipe sign has been a part of the Backuss-Naur form denoting alternatives since the 1960s. It is nowadays usually used in the Extended Backus-Naur form for regular expressions. The Backus-Naur was developed heavily inspired by Noam Chomskys language hierarchy and formalisms for grammar introduced with his book "Syntactic Structures" in the 1950s. Chomsky didn't have pipes, but both BNF and EBNF has. This is the reason why it was in the DTDs, and why it is part of most document description syntaxes. That is: it is not devoid of well-known semantics. This might be a totally off-topic reply in regards to this discussion, but I could not accept that statemant as it stood. > Right, and those should be subtypes of "text" if they can reasonably be > treated as "text/plain", or subtypes of "application" if they contain > non-textual markup. application/xml and text/xml both already exist. What is wrong with them? -- Linus Walleij From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: References: Message-ID: <1050186558.4893.28.camel@felicia> This discussion is new on this list and sound confusing to me. It would be nice to have a briefing on the background facts. For example, I want to know where the *existing* and *used* transport types application/xml text/xml fits into this, and why it shouldn't be used for XHTML like for all other XML derivates. If the browser recognize that this XML file belongs to a certain namespace and should be rendered in a certain way (xhtml-wise) that is in my humble opinion not a *transport* problem. > I would see it as "This resource is of such-and-such type AND it is XML in > terms of syntax." = content type text/xml, and the first row of that XML-compliant file: will tell that it is of such-and-such XML derivative type. This is thus not a transport issue. The transport types are designed to be quite general. A binary file has no standard for deciphering it's contents (well with the exception of say Quicktime and such non-IETF de facto standards) why it has to be carried in it's own transport type. text/xml and application/xml are reserved for XML derivatives. These additionally have clear syntax for describing their context i.e. so they need no additional transport typing. To add it anyway would be unnecessary duplication of information. > I have > to say that the pipe character ("|", vertical line, U+007C) is too devoid of > well-known semantics. This is a technical standard, and the pipe sign has been a part of the Backuss-Naur form denoting alternatives since the 1960s. It is nowadays usually used in the Extended Backus-Naur form for regular expressions. The Backus-Naur was developed heavily inspired by Noam Chomskys language hierarchy and formalisms for grammar introduced with his book "Syntactic Structures" in the 1950s. Chomsky didn't have pipes, but both BNF and EBNF has. This is the reason why it was in the DTDs, and why it is part of most document description syntaxes. That is: it is not devoid of well-known semantics. This might be a totally off-topic reply in regards to this discussion, but I could not accept that statemant as it stood. > Right, and those should be subtypes of "text" if they can reasonably be > treated as "text/plain", or subtypes of "application" if they contain > non-textual markup. application/xml and text/xml both already exist. What is wrong with them? -- Linus Walleij From: duerst at w3.org (Martin Duerst) Date: Sun Apr 13 20:22:38 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <1050186558.4893.28.camel@felicia> References: Message-ID: <4.2.0.58.J.20030413125758.063a0f10@localhost> Hello Ethan, Linus, others, At 14:12 03/04/13 +0200, Linus Walleij wrote: >This discussion is new on this list and sound confusing to me. It would >be nice to have a briefing on the background facts. For background/facts, see 1) RFC 3023 itself, in particular Appendix A (http://www.ietf.org/rfc/rfc3023.txt) 2) The archives of the ietf-xml-mime mailing list, at http://www.imc.org/ietf-xml-mime/mail-archive/maillist.html Please come back to discuss here after you have reviewed these resources. Regards, Martin. >For example, I want to know where the *existing* and *used* transport >types application/xml text/xml fits into this, and why it shouldn't be >used for XHTML like for all other XML derivates. If the browser >recognize that this XML file belongs to a certain namespace and should >be rendered in a certain way (xhtml-wise) that is in my humble opinion >not a *transport* problem. > > > I would see it as "This resource is of such-and-such type AND it is XML in > > terms of syntax." > >= content type text/xml, and the first row of that XML-compliant file: > >"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd"> > >will tell that it is of such-and-such XML derivative type. This is thus >not a transport issue. The transport types are designed to be quite >general. A binary file has no standard for deciphering it's contents >(well with the exception of say Quicktime and such non-IETF de facto >standards) why it has to be carried in it's own transport type. > >text/xml and application/xml are reserved for XML derivatives. These >additionally have clear syntax for describing their context i.e. > so they need no additional transport typing. To add it >anyway would be unnecessary duplication of information. > > > I have > > to say that the pipe character ("|", vertical line, U+007C) is too > devoid of > > well-known semantics. > >This is a technical standard, and the pipe sign has been a part of the >Backuss-Naur form denoting alternatives since the 1960s. It is nowadays >usually used in the Extended Backus-Naur form for regular expressions. >The Backus-Naur was developed heavily inspired by Noam Chomskys language >hierarchy and formalisms for grammar introduced with his book "Syntactic >Structures" in the 1950s. Chomsky didn't have pipes, but both BNF and >EBNF has. This is the reason why it was in the DTDs, and why it is part >of most document description syntaxes. That is: it is not devoid of >well-known semantics. > >This might be a totally off-topic reply in regards to this discussion, >but I could not accept that statemant as it stood. > > > Right, and those should be subtypes of "text" if they can reasonably be > > treated as "text/plain", or subtypes of "application" if they contain > > non-textual markup. > >application/xml and text/xml both already exist. What is wrong with >them? > >-- >Linus Walleij From: duerst at w3.org (Martin Duerst) Date: Sun Apr 13 20:45:56 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <1050186558.4893.28.camel@felicia> References: Message-ID: <4.2.0.58.J.20030413125758.063a0f10@localhost> Hello Ethan, Linus, others, At 14:12 03/04/13 +0200, Linus Walleij wrote: >This discussion is new on this list and sound confusing to me. It would >be nice to have a briefing on the background facts. For background/facts, see 1) RFC 3023 itself, in particular Appendix A (http://www.ietf.org/rfc/rfc3023.txt) 2) The archives of the ietf-xml-mime mailing list, at http://www.imc.org/ietf-xml-mime/mail-archive/maillist.html Please come back to discuss here after you have reviewed these resources. Regards, Martin. >For example, I want to know where the *existing* and *used* transport >types application/xml text/xml fits into this, and why it shouldn't be >used for XHTML like for all other XML derivates. If the browser >recognize that this XML file belongs to a certain namespace and should >be rendered in a certain way (xhtml-wise) that is in my humble opinion >not a *transport* problem. > > > I would see it as "This resource is of such-and-such type AND it is XML in > > terms of syntax." > >= content type text/xml, and the first row of that XML-compliant file: > >"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd"> > >will tell that it is of such-and-such XML derivative type. This is thus >not a transport issue. The transport types are designed to be quite >general. A binary file has no standard for deciphering it's contents >(well with the exception of say Quicktime and such non-IETF de facto >standards) why it has to be carried in it's own transport type. > >text/xml and application/xml are reserved for XML derivatives. These >additionally have clear syntax for describing their context i.e. > so they need no additional transport typing. To add it >anyway would be unnecessary duplication of information. > > > I have > > to say that the pipe character ("|", vertical line, U+007C) is too > devoid of > > well-known semantics. > >This is a technical standard, and the pipe sign has been a part of the >Backuss-Naur form denoting alternatives since the 1960s. It is nowadays >usually used in the Extended Backus-Naur form for regular expressions. >The Backus-Naur was developed heavily inspired by Noam Chomskys language >hierarchy and formalisms for grammar introduced with his book "Syntactic >Structures" in the 1950s. Chomsky didn't have pipes, but both BNF and >EBNF has. This is the reason why it was in the DTDs, and why it is part >of most document description syntaxes. That is: it is not devoid of >well-known semantics. > >This might be a totally off-topic reply in regards to this discussion, >but I could not accept that statemant as it stood. > > > Right, and those should be subtypes of "text" if they can reasonably be > > treated as "text/plain", or subtypes of "application" if they contain > > non-textual markup. > >application/xml and text/xml both already exist. What is wrong with >them? > >-- >Linus Walleij From: ewexler at stickdog.com (Etan Wexler) Date: Tue Jan 3 16:22:35 2006 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <3E94185F.10003@cc.jyu.fi> Message-ID: Mikko Rantalainen wrote to on 9 April 2003 in "Re: XHTML2 MIME type" (): > [This is getting a bit offtopic and I'm not really expecting any > replies. I'll post some thoughts to help future archive diggers.] I'm steering the discussion into the MIME media types list, . Please send public replies there. > OK. This is the first time I actually viewed RFC 3023 and I want to say > that I consider "+xml" extension as an ugly hack. I consider it an elegant solution. Our difference leads me to conclude that this is at least partly a matter of taste. De gustibus non disputandum. > I'm still wondering why they choose > to use "+" as a separator if the meaning is "this file can be considered > as something OR xml". I would see it as "This resource is of such-and-such type AND it is XML in terms of syntax." > When I first time saw application/xhtml+xml I > immediatly thought that it meant it's an xhtml file with possible > additional namespaces. While I affirm the principle that MIME media type names should be as clear as is possible within the limited character repertoire and some reasonable length, we have IANA registrations and Requests For Comments that define each type. Those documents are meant for reading, not for ignoring. > As I have some programming background I think > application/xhtml|xml would have been much better and the pipe was > available in addition to the plus sign. As I know that non-programmer lay people encounter MIME media type names with some frequency on the Web (by "Web" I'm including mail systems), I have to say that the pipe character ("|", vertical line, U+007C) is too devoid of well-known semantics. In my experience in the English-speaking United States, if there is any character that commonly denotes alternatives, it is the slash ("/", solidus, U+002F). (Perhaps, in that case, I should have written slash/solidus.) The slash is reserved and will not find its way into a MIME media subtype name. > After reading the references you provided I still feel that we need a > new top level mime type. We have various file types that are basically > text but not plain text. Right, and those should be subtypes of "text" if they can reasonably be treated as "text/plain", or subtypes of "application" if they contain non-textual markup. > If the reason for not having another top level MIME type for xml/* is > that we want to specify TYPE instead of SYNTAX then the text/* shouldn't > be considered as plain text syntax either and it should be used for all > file types that mostly contain text. I think that the principle in effect is that treatment as "text/plain" has to be a reasonable fallback for any "text" subtype. What constitutes reasonable is a matter for debate. I suspect that most people could not make sense of Postscript source code (hence "application/postscript"), even though it is textual. HTML source code, on the other hand, is likely to contain passages of readable text (hence "text/html"), even if it leaves the reader wondering what all the symbols mean. > I think the application/* top level type shouldn't be used for XHTML 2 > just because one needs an application to easily read the content. My understanding is that the MIME media type name "application" describes the content itself, not the necessary processing software. It's like "This resource is an application of some sort", not like "Start an application to handle this resource". > Following the same logic we should move all of image/*, video/* and > audio/* types to application/* because you cannot view any of those > without an application either. Again, the term "application" describes the resource, not the handler. > Perhaps application/* should be renamed to misc/* or other/*? That sounds like a terrible idea, given the installed base of software that understands and expects the "application" name. -- Etan Wexler: stuffed but not satiated, damn it. From: ewexler at stickdog.com (Etan Wexler) Date: Sat Apr 12 02:39:34 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <3E94185F.10003@cc.jyu.fi> Message-ID: Mikko Rantalainen wrote to on 9 April 2003 in "Re: XHTML2 MIME type" (): > [This is getting a bit offtopic and I'm not really expecting any > replies. I'll post some thoughts to help future archive diggers.] I'm steering the discussion into the MIME media types list, . Please send public replies there. > OK. This is the first time I actually viewed RFC 3023 and I want to say > that I consider "+xml" extension as an ugly hack. I consider it an elegant solution. Our difference leads me to conclude that this is at least partly a matter of taste. De gustibus non disputandum. > I'm still wondering why they choose > to use "+" as a separator if the meaning is "this file can be considered > as something OR xml". I would see it as "This resource is of such-and-such type AND it is XML in terms of syntax." > When I first time saw application/xhtml+xml I > immediatly thought that it meant it's an xhtml file with possible > additional namespaces. While I affirm the principle that MIME media type names should be as clear as is possible within the limited character repertoire and some reasonable length, we have IANA registrations and Requests For Comments that define each type. Those documents are meant for reading, not for ignoring. > As I have some programming background I think > application/xhtml|xml would have been much better and the pipe was > available in addition to the plus sign. As I know that non-programmer lay people encounter MIME media type names with some frequency on the Web (by "Web" I'm including mail systems), I have to say that the pipe character ("|", vertical line, U+007C) is too devoid of well-known semantics. In my experience in the English-speaking United States, if there is any character that commonly denotes alternatives, it is the slash ("/", solidus, U+002F). (Perhaps, in that case, I should have written slash/solidus.) The slash is reserved and will not find its way into a MIME media subtype name. > After reading the references you provided I still feel that we need a > new top level mime type. We have various file types that are basically > text but not plain text. Right, and those should be subtypes of "text" if they can reasonably be treated as "text/plain", or subtypes of "application" if they contain non-textual markup. > If the reason for not having another top level MIME type for xml/* is > that we want to specify TYPE instead of SYNTAX then the text/* shouldn't > be considered as plain text syntax either and it should be used for all > file types that mostly contain text. I think that the principle in effect is that treatment as "text/plain" has to be a reasonable fallback for any "text" subtype. What constitutes reasonable is a matter for debate. I suspect that most people could not make sense of Postscript source code (hence "application/postscript"), even though it is textual. HTML source code, on the other hand, is likely to contain passages of readable text (hence "text/html"), even if it leaves the reader wondering what all the symbols mean. > I think the application/* top level type shouldn't be used for XHTML 2 > just because one needs an application to easily read the content. My understanding is that the MIME media type name "application" describes the content itself, not the necessary processing software. It's like "This resource is an application of some sort", not like "Start an application to handle this resource". > Following the same logic we should move all of image/*, video/* and > audio/* types to application/* because you cannot view any of those > without an application either. Again, the term "application" describes the resource, not the handler. > Perhaps application/* should be renamed to misc/* or other/*? That sounds like a terrible idea, given the installed base of software that understands and expects the "application" name. -- Etan Wexler: stuffed but not satiated, damn it. From: ewexler at stickdog.com (Etan Wexler) Date: Sat Apr 12 03:00:56 2003 Subject: XHTML, XML, fancy text, and applications In-Reply-To: <3E94185F.10003@cc.jyu.fi> Message-ID: Mikko Rantalainen wrote to on 9 April 2003 in "Re: XHTML2 MIME type" (): > [This is getting a bit offtopic and I'm not really expecting any > replies. I'll post some thoughts to help future archive diggers.] I'm steering the discussion into the MIME media types list, . Please send public replies there. > OK. This is the first time I actually viewed RFC 3023 and I want to say > that I consider "+xml" extension as an ugly hack. I consider it an elegant solution. Our difference leads me to conclude that this is at least partly a matter of taste. De gustibus non disputandum. > I'm still wondering why they choose > to use "+" as a separator if the meaning is "this file can be considered > as something OR xml". I would see it as "This resource is of such-and-such type AND it is XML in terms of syntax." > When I first time saw application/xhtml+xml I > immediatly thought that it meant it's an xhtml file with possible > additional namespaces. While I affirm the principle that MIME media type names should be as clear as is possible within the limited character repertoire and some reasonable length, we have IANA registrations and Requests For Comments that define each type. Those documents are meant for reading, not for ignoring. > As I have some programming background I think > application/xhtml|xml would have been much better and the pipe was > available in addition to the plus sign. As I know that non-programmer lay people encounter MIME media type names with some frequency on the Web (by "Web" I'm including mail systems), I have to say that the pipe character ("|", vertical line, U+007C) is too devoid of well-known semantics. In my experience in the English-speaking United States, if there is any character that commonly denotes alternatives, it is the slash ("/", solidus, U+002F). (Perhaps, in that case, I should have written slash/solidus.) The slash is reserved and will not find its way into a MIME media subtype name. > After reading the references you provided I still feel that we need a > new top level mime type. We have various file types that are basically > text but not plain text. Right, and those should be subtypes of "text" if they can reasonably be treated as "text/plain", or subtypes of "application" if they contain non-textual markup. > If the reason for not having another top level MIME type for xml/* is > that we want to specify TYPE instead of SYNTAX then the text/* shouldn't > be considered as plain text syntax either and it should be used for all > file types that mostly contain text. I think that the principle in effect is that treatment as "text/plain" has to be a reasonable fallback for any "text" subtype. What constitutes reasonable is a matter for debate. I suspect that most people could not make sense of Postscript source code (hence "application/postscript"), even though it is textual. HTML source code, on the other hand, is likely to contain passages of readable text (hence "text/html"), even if it leaves the reader wondering what all the symbols mean. > I think the application/* top level type shouldn't be used for XHTML 2 > just because one needs an application to easily read the content. My understanding is that the MIME media type name "application" describes the content itself, not the necessary processing software. It's like "This resource is an application of some sort", not like "Start an application to handle this resource". > Following the same logic we should move all of image/*, video/* and > audio/* types to application/* because you cannot view any of those > without an application either. Again, the term "application" describes the resource, not the handler. > Perhaps application/* should be renamed to misc/* or other/*? That sounds like a terrible idea, given the installed base of software that understands and expects the "application" name. -- Etan Wexler: stuffed but not satiated, damn it.