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


Hi, DITA-Minded Technical Committee:

I thought it might be useful to do another refresh on the mime type thread based on the latest contributions from Jeff and Paul.


Thanks,


Erik Hennum
ehennum@us.ibm.com


======================
= A mime type for DITA
======================


MOTIVATION:

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.


REQUIREMENT:

The mime type identifies DITA documents so tools can distinguish DITA documents from other kinds of documents without opening the document and can route DITA documents to DITA-aware tools.


OPTIONS:

1. The mime type (application/dita+xml) identifies a document governed by the DITA specification. A required format parameter identifies the base vocabulary for the DITA document with the same values as the DITA map (dita, ditamap, or ditaval). An optional type parameter identifies the specialization of the DITA vocabulary.

2. The mime type (application/dita+xml) identifies a document extensible by DITA specialization. A required format parameter identifies the base vocabulary for the DITA document with the same values as the DITA map (dita or ditamap). An optional type parameter identifies the specialization of the DITA vocabulary. Additional mime types identify DITA documentats that are extensible by specialization (application/ditaval+xml).

3. The mime type (application/dita+xml and application/ditamap+xml) identifies a DITA base vocabulary. An optional type parameter identifies the specialization of the DITA vocabulary. Additional mime types identify DITA documentats that are extensible by specialization (application/ditaval+xml).

For background on parameters, the RFC 2046 standard allows additional Content-Type parameters like format:


The character set and encoding parameters of the mime type would be required but have no DITA-specific considerations.


QUESTIONS:


FORMAT PARAMETER: Is it better to provide a different mime type for each base vocabulary or to require a non-standard format parameter?

Either way, topics of ditabase aren't a distinct base vocabulary (they are merely topic documents with a list of topics rather than a single topic) and thus shouldn't have a separate mime type or format.


TYPE PARAMETER: 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.


NAVTITLE PARAMETER: Do we want to add an optional navtitle parameter?

Pros would be to minimize the need to open the document.

Cons would be that different processors may need different titles (navtitle, searchtitle, topic/title), the same topic can have different navtitles in different contexts, some processors may need something other or in addition to the title (metadata, shortdesc). Also, the case could be made that the map or atom would be better carriers of summary information about a topic than the mime type record.


REFERENCE:

Informative
http://en.wikipedia.org/wiki/MIME
http://www.iana.org/assignments/media-types/

Normative
http://tools.ietf.org/html/rfc2046 or ftp://ftp.ietf.org/rfc/rfc2046.txt
http://tools.ietf.org/html/rfc3023 or ftp://ftp.ietf.org/rfc/rfc3023.txt


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