Subject: XHTML, XML, fancy text, and applications
From: dan at dankohn.com (Dan Kohn)
Date: Tue Jan 3 16:22:35 2006

>> 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 <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
>From [email-masked]  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: <[email-masked]>

>> 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 <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

From: dan at dankohn.com (Dan Kohn)
Date: Mon Apr 21 17:39:11 2003
Subject: XHTML, XML, fancy text, and applications
Message-ID: <[email-masked]>

>> 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 <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
>From [email-masked]  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: <[email-masked]>

>> 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 <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

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: <[email-masked]>

This email serves to instantiate the two weeks discussion period on
"[email-masked]" 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, [email-masked]
   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:[email-masked]

   Mark Nottingham
   BEA Systems
   Level 15, 235 Montgomery Street
   San Francisco, CA, US.  94104
   mailto:[email-masked]

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.
         <http://www.w3.org/TR/2002/CR-soap12-part1-20021219>. 
>From [email-masked]  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: <[email-masked]>
Message-ID: <[email-masked]>

Mikko Rantalainen wrote to <mailto:[email-masked]> on 9 April 2003 in "Re:
XHTML2 MIME type" (<mid:[email-masked]>):

> [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,
<mailto:[email-masked]>. 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.
 <mailto:[email-masked]>

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: <[email-masked]>

This email serves to instantiate the two weeks discussion period on
"[email-masked]" 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, [email-masked]
   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:[email-masked]

   Mark Nottingham
   BEA Systems
   Level 15, 235 Montgomery Street
   San Francisco, CA, US.  94104
   mailto:[email-masked]

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.
         <http://www.w3.org/TR/2002/CR-soap12-part1-20021219>. 

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: <[email-masked]>
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 ([email-masked]) 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: <[email-masked]>
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 ([email-masked]) 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: <[email-masked]> <1050186558.4893.28.camel@felicia>
Message-ID: <[email-masked]>

On Sun, 13 Apr 2003 14:12:17 +0200
Linus Walleij <[email-masked]> 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 <[email-masked]>

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: <[email-masked]> <[email-masked]> <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: <[email-masked]> <[email-masked]> <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: <[email-masked]> <1050186558.4893.28.camel@felicia>
Message-ID: <[email-masked]>

On Sun, 13 Apr 2003 14:12:17 +0200
Linus Walleij <[email-masked]> 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 <[email-masked]>

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: <[email-masked]> <[email-masked]>
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:
>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>"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.
><!DOCTYPE ...> 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 <[email-masked]>

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: <[email-masked]> <[email-masked]>
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:
>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>"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.
><!DOCTYPE ...> 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 <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
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:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"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.
<!DOCTYPE ...> 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 <[email-masked]>

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: <[email-masked]>
References: <[email-masked]>
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:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"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.
<!DOCTYPE ...> 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 <[email-masked]>

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: <[email-masked]> <[email-masked]>
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:
>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>"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.
><!DOCTYPE ...> 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 <[email-masked]>

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: <[email-masked]> <[email-masked]>
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:
>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>"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.
><!DOCTYPE ...> 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 <[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

Mikko Rantalainen wrote to <mailto:[email-masked]> on 9 April 2003 in "Re:
XHTML2 MIME type" (<mid:[email-masked]>):

> [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,
<mailto:[email-masked]>. 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.
 <mailto:[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

Mikko Rantalainen wrote to <mailto:[email-masked]> on 9 April 2003 in "Re:
XHTML2 MIME type" (<mid:[email-masked]>):

> [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,
<mailto:[email-masked]>. 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.
 <mailto:[email-masked]>

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: <[email-masked]>
Message-ID: <[email-masked]>

Mikko Rantalainen wrote to <mailto:[email-masked]> on 9 April 2003 in "Re:
XHTML2 MIME type" (<mid:[email-masked]>):

> [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,
<mailto:[email-masked]>. 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.
 <mailto:[email-masked]>