OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: mime type for DITA?

Hi, Technical Committee:

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

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:

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

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

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:

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:

Hoping that's useful,

Erik Hennum

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]