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 (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
ehennum@us.ibm.com

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



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