- From: <mmurata@trl.ibm.co.jp>
- Date: Wed, 13 Dec 2000 14:54:03 +0900 (LMT)
- To: xml-dist-app@w3.org
- Cc: mmurata@trl.ibm.co.jp
Please read the I-D which will be promoted to a Proposed Standard of IETF very soon. http://search.ietf.org/internet-drafts/draft-murata-xml-09.txt Larry, I think that application/xml is good enough, but application/soap+xml might be more appropriate. Up to you. Cheers, Makoto >3. XML Media Types ... > If an XML document -- that is, the unprocessed, source XML document > -- is readable by casual users, text/xml is preferable to > application/xml. MIME user agents (and web user agents) that do not > have explicit support for text/xml will treat it as text/plain, for > example, by displaying the XML entity as plain text. Application/xml > is preferable when the XML MIME entity is unreadable by casual > users. Similarly, text/xml-external-parsed-entity is preferable when > an external parsed entity is readable by casual users, but > application/xml-external-parsed-entity is preferable when a plain > text display is inappropriate. > > NOTE: Users are in general not used to text containing tags such > as <price>, and often find such tags quite disorienting or > annoying. If one is not sure, the conservative principle would > suggest using application/* instead of text/* so as not to put > information in front of users that they will quite likely not > understand. ... > 7. A Naming Convention for XML-Based Media Types > > This document recommends the use of a naming convention (a suffix of > '+xml') for identifying XML-based MIME media types, whatever their > particular content may represent. This allows the use of generic XML > processors and technologies on a wide variety of different XML > document types at a minimum cost, using existing frameworks for > media type registration. > > Although the use of a suffix was not considered as part of the > original MIME architecture, this choice is considered to provide the > most functionality with the least potential for interoperability > problems or lack of future extensibility. The alternatives to the > '+xml' suffix and the reason for its selection are described in > Appendix A. > > As XML development continues, new XML document types are appearing > rapidly. Many of these XML document types would benefit from the > identification possibilities of a more specific MIME media type than > text/xml or application/xml can provide, and it is likely that many > new media types for XML-based document types will be registered in > the near and ongoing future. > > 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] or [XSLT] 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 (work in progress) can work > with any XML document, whatever vocabulary it uses and whether or > not it uses XPointer for its own fragment identification. > > o Hypertext linking - XLink (work in progress) hypertext linking is > designed to connect any XML documents, regardless of vocabulary. > > o Searching - XML-oriented search engines, web crawlers, agents, > and query tools should be able to read XML documents and extract > the names and content of elements and attributes even if the > tools are ignorant of the particular vocabulary used for elements > and attributes. > > > > Murata, et. al. Expires March 20, 2001 [Page 19] > > Internet-Draft XML Media Types September 2000 > > > 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. > > o Well-formedness and validity checking - An XML processor can > confirm that any XML document is well-formed and that it is valid > (i.e., conforms to its declared DTD or Schema). > > When a new media type is introduced for an XML-based format, the > name of the media type SHOULD end with '+xml'. This convention will > allow applications that can process XML generically to detect that > the MIME entity is supposed to be an XML document, verify this > assumption by invoking some XML processor, and then process the XML > document accordingly. Applications may match for types that > represent XML entities by comparing the subtype to the pattern > '*/*+xml'. (Of course, 4 of the 5 media types defined in this > document -- text/xml, application/xml, > text/xml-external-parsed-entity, and > application/xml-external-parsed-entity -- also represent XML > entities while not conforming to the '*/*+xml' pattern.) > > NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept > headers of the form "Accept: */*+xml" and so this header MUST NOT > be used in this way. Instead, content negotiation[RFC2703] could > potentially be used if an XML-based MIME type were needed. > > XML generic processing is not always appropriate for XML-based media > types. For example, authors of some such media types may wish that > the types remain entirely opaque except to applications that are > specifically designed to deal with that media type. By NOT following > the naming convention '+xml', such media types can avoid XML-generic > processing. Since generic processing will be useful in many cases, > however -- including in some situations that are difficult to > predict ahead of time -- those registering media types SHOULD use > the '+xml' convention unless they have a particularly compelling > reason not to. > > The registration process for these media types is described in > [RFC2048]. The registrar for the IETF tree will encourage new > XML-based media type registrations in the IETF tree to follow this > guideline. Registrars for other trees SHOULD follow this convention > in order to ensure maximum interoperability of their XML-based > documents. Similarly, media subtypes that do not represent XML > entities MUST NOT be allowed to register with a '+xml' suffix.
Received on Wednesday, 13 December 2000 01:00:32 UTC