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: RE: [dita] mime type for DITA

Also ftp://ftp.ietf.org/rfc/rfc2046.txt gives MIME registration procedures and http://www.iana.org/assignments/media-types/ gives an overview and other pointers about mime type registration.

From: Grosso, Paul [mailto:pgrosso@ptc.com]
Sent: Saturday, 2008 April 19 8:44
To: Erik Hennum; dita@lists.oasis-open.org
Subject: RE: [dita] mime type for DITA

See also RFC 3023 at ftp://ftp.ietf.org/rfc/rfc3023.txt.

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Friday, 2008 April 18 19:57
To: dita@lists.oasis-open.org
Subject: [dita] mime type for DITA

Hi, DITA-Minded Technical Committee:

I thought it might be useful to refresh the thread about mime types with a summary of the proposal prior to the meeting.

This proposal is really a light modification on Jeff's analysis. (Jeff, do you have an RFC reference for the format and type mimetype keywords? I could swear I've seen them but can't find it for the life of me.)

Please note the DISCUSSION item below about the type.


Erik Hennum

= A mime type for DITA


Where client tools needs to download documents from a CMS (potentially via WebDAV) and route requests to open those documents to the desktop editor that understands DITA specialization.

Such client tools needs to distingish DITA topics and maps (with base or specialized vocabularies) from other XML documents (XMI, SVG, what have you) provided by the CMS system. The CMS typically stores the document without an extension, so the tool can't rely on file-system mechanisms for recognizing DITA vocabularies. If the tool simply passes through the document from the CMS to the client Operating System, the web brower might open the XML topic instead of the DITA-aware editor. Without a MIME type, the tool will have to open and parse the initial part of the file to recognize DITA topics and maps, which will be very inefficient.


The mime type record (such as an HTTP header) has the following fields:

* The application/dita+xml mime type identifies any document that use DITA specialization.
* The format property identifies the base vocabulary for the specialized document (in particular, topic or map).
* The type property identifies the specialized vocabulary.

The character set and encoding fields have no DITA-specific considerations.

NOTE: Topics of ditabase don't have a separate format because they are just topic documents with a list of topics rather than a single topic.

NOTE: Because it doesn't have specialization, the DITA values file requires a separate mime type of application/ditaval+xml. If it ever becomes specialized, the mime type of application/dita+xml and format of ditaval would be applicable.

DISCUSSION: The type property could reflect either:

* The type of the root topic, first topic (for ditabase), or map by using the class attribute (replacing spaces with a legal separator character)
* The name of the shell

The case for using the topic type: Fallback processing becomes possible for the root type prior to opening the document. If the document is declared as javaClass and the receiver understands apiClassifier, the receiver knows that it can process the vocabulary before opening the document. If the receiver cares about domains or subtopics, however, the receiver must open the topic to detect them.

The case for declaring the shell: If the receiver knows the shell, the receiver understands everything about the document without opening it including the root type, nested topics or topics after the first for ditabase as well as domains in either topic or map. If the receiver doesn't know the shell identifier, however, the receiver would have to open the document to determine fallback processing.



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