mime type for DITA?

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Technical Committee:

Returning to an old question, should the committee take a position with respect to a mime type for DITA?

http://lists.oasis-open.org/archives/dita/200408/msg00055.html

A DITA mime type would let tools declare and recognize DITA content in HTTP headers, email, and so on without actually inspecting the content.  As I understand Paul's note, a mime type would also provide a basis for defining the DITA reference syntax within URI standards:

http://lists.oasis-open.org/archives/dita/200705/msg00040.html

One might expect DITA to have a mime type similar to application/dita+xml following ordinary practice for XML vocabularies:

http://en.wikipedia.org/wiki/XML_and_MIME

DITA is an architecture, however, not a vocabulary.  Section A.14 in the relevant RFC suggests that an extensible architecture should prepend qualification levels:

ftp://ftp.isi.edu/in-notes/rfc3023.txt

Applied to DITA, that would seem to call for a mime type that separates the declaration of the vocabulary (as defined by the shell for the document type) from the DITA architecture from the XML architecture.  

An application that recognizes a document type can process any document that generalizes to a valid instance of the recognized document type.  Because of shell pluggability, however, the mime type alone can't reasonably provide a basis for determining the compatibility of a document type accepted by an application with the document type of the supplied document.  (The mime type for the document type would have to encode the modules and ancestor modules included by the shell, effectively cramming the value of the domains attribute into an identifier.)

A reasonable compromise might be for the mime type to identify only the base vocabulary.  (That compromise also acknowledges the impracticality of registering all DITA shells as mime types.)  Applications would have to inspect the domains attribute in the content for more specific evaluation of acceptability.  This approach avoids creating a legacy that would have to be accomodated if future work solves the document type compatibility problem some other way.

In summary, this approach would introduce two fundamental mime types for topics and maps:

application/topic+dita+xml
application/map+dita+xml

Because the DITA values file isn't specializable (doesn't provide the architecture attributes), their mime types should identify the XML vocabulary but not the DITA architecture:

application/ditaval+xml

Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com