Re: text/xml for SOAP (and XP) considered harmful

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