RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Dan Kohn <dan@teledesic.com> Fri, 10 March 2000 22:19 UTC
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA28191 for ietf-xml-mime-bks; Fri, 10 Mar 2000 14:19:45 -0800 (PST)
Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28166; Fri, 10 Mar 2000 14:18:50 -0800 (PST)
Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2448.0) id <GV9RNDQ0>; Fri, 10 Mar 2000 14:15:45 -0800
Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0517D06@tdmail2.teledesic.com>
From: Dan Kohn <dan@teledesic.com>
To: 'Keith Moore' <moore@cs.utk.edu>, "'ietf-822@imc.org'" <ietf-822@imc.org>, "'ietf-xml-mime@imc.org'" <ietf-xml-mime@imc.org>
Cc: ietf-types@iana.org, "Martin J. Duerst" <duerst@w3.org>, MURATA Makoto <muraw3c@attglobal.net>, ned.freed@INNOSOFT.COM, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Date: Fri, 10 Mar 2000 14:08:57 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-xml-mime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>
I am cross-posting to ietf-822@imc.org because Keith correctly points out that <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt> raises fundamental architectural questions regarding the right way to integrate XML and MIME. Those issues have been discussed on ietf-xml-mime@imc.org and I believe a rough consensus was achieved, but the purpose of this thread is to try to confirm that. >why? is there really much value in a default treatment of text/* xml >documents as plain text? (the default doesn't seem to work well in >practice for text/html) or is xml really likely to be used for >image/*, audio/*, video/*, or model/* content? >how do you figure that? such categorization is the primary purpose of >top-level types. and while I grant that XML could be used to represent >images, audio, or video...it does not seem well-suited as a presentation >layer for these. Keith, I think this may be the crux of the disagreement. For the "-xml" suffix to make sense, I think it must be likely that XML structure data will show up in multiple MIME top-level types AND that that data could be generically processed in a useful way. Those two constraints would imply that XML is acting fundamentally as the presentation layer in the network stack (apologies for obligatory OSI network stack reference), and that that presentation information should be available to dispatchers that can make use if it. The fact that almost all subtypes based on XML can be generically processed is addressed in the I-D and excerpted in my message, which I attach below. As to whether subtypes based on XML belong in different top-level type, I believe the following examples demonstrate that XML-based data types will most likely be registered in ALL top-level categories: Application/*: IOTP <http://www.normos.org/ietf/draft/draft-ietf-trade-iotp-v1.0-protocol-07.txt > RDF <http://www.w3.org/RDF/> MathML <http://www.w3.org/Math/> Audio/*: Nothing yet, but don't rule out VXML <http://www.vxml.org/> or a derivative SMIL is also a possibility <http://www.w3.org/AudioVideo/>. Also, note that XML modularization <http://www.w3.org/TR/xhtml-modularization/> makes it quite likely that new XML subtypes will be created that serve specific needs, and encoding binary audio information is completely feasible. Video/*: SMIL and/or a derivative could be registered here or in Application/* <http://www.w3.org/AudioVideo> Model/*: UML <http://www.omg.org/uml/> (may be under Application/*) If VRML were being started from scratch today it would likely be built in XML. See <http://www.vrml.org/WorkingGroups/dbwork/vrmlxml.html> for some integration discussion. Image/*: SVG <http://www.w3.org/Graphics/SVG/> Text/*: XHTML <http://www.w3.org/TR/xhtml1/>, though this is better under Application/* - dan -- Daniel Kohn <mailto:dan@dankohn.com> tel:+1-425-602-6222 fax:+1-425-602-6223 http://www.dankohn.com -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, 2000-03-10 11:38 To: Dan Kohn Cc: Keith Moore; ietf-types@iana.org; Martin J. Duerst; MURATA Makoto; ned.freed@INNOSOFT.COM; Donald E. Eastlake 3rd Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) > >okay - more generally, I don't think we should make a special case in > >the MIME content-type syntax (not even using an ad hoc mechanism) > >for content-types that happen to be based on XML. MIME already has > >a mechanism to define default handling of certain classes of objects, > >in the top-level content-type. If there's really enough utility in > >doing this for XML, we should create an xml/ top-level type. > >We shouldn't create another separate syntactical convention to do this. > > Keith, take two potential types, image/svg-xml and application/mathml-xml. > In both cases, for dispatchers that don't understand or care about XML, the > "-xml" suffix is completely opaque. it may be opaque, but it still does harm if it constrains evolution of the MIME content-type space. > These subtypes need to be under > existing top-level types in order to be dispatched correctly. why? is there really much value in a default treatment of text/* xml documents as plain text? (the default doesn't seem to work well in practice for text/html) or is xml really likely to be used for image/*, audio/*, video/*, or model/* content? > A new XML > top-level type doesn't provide any information of categorization, because > XML-based MIME types can fall in any of the top level categories. how do you figure that? such categorication is the primary purpose of top-level types. and while I grant that XML could be used to represent images, audio, or video...it does not seem well-suited as a presentation layer for these. but this again begs the question about how much encoding information you want to make explicit in the content-type name. and my main point is that the answer is not obvious - embedding -xml in the name comes at a cost. we need to think carefully before either (a) establishing yet another syntactic convention for content-type names, or (b) making XML explicit in a content-type name. and this is is a MIME architectural issue - it isn't something that should be done just because XML proponents think it is a good idea. if there is going to be such a convention, it needs to be carefully considered both for its impact on the MIME architecture and whether it's actually desirable to do this for XML. (the latter is easier to justify than the former) > In summary, there is no downside to using the "-xml" suffix disagree. see above. Keith -----Original Message----- From: Dan Kohn Sent: Friday, 2000-03-10 11:19 To: Keith Moore Cc: ietf-types@iana.org; Martin J. Duerst; MURATA Makoto; ned.freed@INNOSOFT.COM; Donald E. Eastlake 3rd Subject: reason for application/iotp-xml (was RE: Registration of MIME media type APPLICATION/IOTP) Keith Moore said: >okay - more generally, I don't think we should make a special case in >the MIME content-type syntax (not even using an ad hoc mechanism) >for content-types that happen to be based on XML. MIME already has >a mechanism to define default handling of certain classes of objects, >in the top-level content-type. If there's really enough utility in >doing this for XML, we should create an xml/ top-level type. >We shouldn't create another separate syntactical convention to do this. Keith, take two potential types, image/svg-xml and application/mathml-xml. In both cases, for dispatchers that don't understand or care about XML, the "-xml" suffix is completely opaque. These subtypes need to be under existing top-level types in order to be dispatched correctly. A new XML top-level type doesn't provide any information of categorization, because XML-based MIME types can fall in any of the top level categories. However, for dispatchers that do understand XML, and especially for those that haven't seen a specific type before (such as application/iotp-xml), the "-xml" suffix provides additional information that the content could instead be dispatched to an XML browser or processed generically in various ways. In the IOTP example, this could be very useful in allowing someone not configured to deal with the subtype to at least have the information displayed in an accessible way. Of course, if the dispatcher is configured to deal with IOTP, then the "-xml" remains opaque. In summary, there is no downside to using the "-xml" suffix, but significant potential functionality can be gained. To quote <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt>: While the benefits of specific MIME types for particular types of XML documents are significant, all XML documents share common structures and syntax that make possible common processing. Some areas where 'generic' processing is useful include: o Browsing - An XML browser can display any XML document with a provided CSS[12] or XSLT[19] style sheet, whatever the vocabulary of that document. o Editing - Any XML editor can read, modify, and save any XML document. o Fragment identification - XPointers[16] can work with any XML document, whatever vocabulary it uses and whether or not it uses XPointer for its own fragment identification. [Editor's note: the use of non-XPointer fragment identifiers by XML vocabularies like SVG and SMIL requires further discussion.] o Hypertext Linking - XLink[17] hypertext linking is designed to connect any XML documents, regardless of vocabulary. o Searching - Search engines, agents, and XML-oriented query tools should be able to read XML documents and extract the content and names of elements and attributes even if they are ignorant of the particular vocabulary used for elements and attributes. o Storage - XML-oriented storage systems, which keep XML documents internally in a parsed form, should similarly be able to process, store, and recreate any XML document. Also, note that Murata-san's draft has specific "opt-out" language if your XML-based MIME type is not suitable for generic processing: XML-generic processing is not always appropriate for XML-based media types. For example, some such media types may require fragment identifiers different from XPointer. By *not* following the naming convention */*-xml, such media types can avoid XML-generic processing. However, I would suggest that application/iotp-xml is a perfect illustration of the utility of suffix-based naming. - dan P.S. Please use ietf-types@iana.org, which is the permanent address for this list, rather than ietf-types@uninett.no. -- Daniel Kohn <mailto:dan@dankohn.com> tel:+1-425-602-6222 fax:+1-425-602-6223 http://www.dankohn.com
- RE: reason for application/iotp-xml (was RE: Regi… Pete Resnick
- Re: reason for application/iotp-xml (was RE: Regi… Keith Moore
- RE: reason for application/iotp-xml (was RE: Regi… Graham Klyne
- Re: reason for application/iotp-xml Keith Moore
- Re: reason for application/iotp-xml D. J. Bernstein
- Re: reason for application/iotp-xml (was RE: Regi… ned.freed
- RE: reason for application/iotp-xml (was RE: Regi… ned.freed
- Re: reason for application/iotp-xml (was RE: Regi… Keith Moore
- RE: reason for application/iotp-xml (was RE: Regi… Scott Lawrence
- Re: reason for application/iotp-xml (was RE: Regi… MURATA Makoto
- Re: reason for application/iotp-xml (was RE: Regi… Tim Bray
- Re: reason for application/iotp-xml (was RE: Regi… Paul Hoffman / IMC
- Re: reason for application/iotp-xml (was RE: Regi… Tim Bray
- Re: reason for application/iotp-xml D. J. Bernstein
- Re: reason for application/iotp-xml (was RE: Regi… Paul Hoffman / IMC
- RE: reason for application/iotp-xml (was RE: Regi… Dan Kohn
- RE: reason for application/iotp-xml (was RE: Regi… Dan Kohn