← Prev in month
← Prev in thread
mime type for DITA (2)
Hi, Judicious Technical Committee: In followup to last week's conversation, I contacted Nathaniel S Borenstein, one of the originators of MIME types. Nathaniel's opinion was that any of the three options below was fully consistent with prevailing MIME type practices. He had a slight preference for the first option (application/dita+xml means a document governed by the DITA standard) as the simplest. I think the TC was leaning in the same direction. If that's acceptable, the remaining issues for discussion would be the format, type, and navtitle parameters. Thanks, Erik Hennum Erik Hennum/Oakland/IBM wrote on 04/22/2008 07:42:41 AM: > > ====================== > = 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: > > After the type and subtype names, the remainder of the header field > is simply a set of parameters, specified in an attribute/value > notation. The ordering of parameters is not significant. > > Parameters are modifiers of the media subtype, and as such do not > fundamentally affect the nature of the content. The set of > meaningful parameters depends on the media type and subtype. Most > parameters are associated with a single specific subtype. However, > a given top-level media type may define parameters which are > applicable to any subtype of that type. Parameters may be required > by their defining media type or subtype or they may be optional. > MIME implementations must also ignore any parameters whose names > they do not recognize. > > 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
← Prev in month
← Prev in thread