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 (2)

Erik Hennum <ehennum@us.ibm.com> wrote on 30/04/2008 12:42:57 AM:
> If that's acceptable, the remaining issues for discussion would be
> the format, type, and navtitle parameters.

> > 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.
> > FORMAT PARAMETER:   Is it better to provide a different mime type
> > for each base vocabulary or to require a non-standard format parameter?

Hypothetically, imagine that a future DITA TC adds a new base vocabulary to DITA, in addition to topic, map and ditaval.  The decision made here would dictate whether the corresponding MIME type is "application/ditafoo+xml" or "application/dita+xml; format=foo".  The latter is more practical than the former because:
1. The latter still identifies itself as DITA to applications that are interested in DITAness but not the format; the former requires risky substring operations.
2. The latter doesn't require additional registration of MIME types, only a modification of the existing application/dita+xml spec.
3. The former would require millions of mime.types files to be updated on servers; the latter might not if implemented correctly.

> > 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 separatorcharacter)
> > * The name of the shell

A shell name by itself ("apiref.dtd") is probably not useful.  There is no information there about *whose* apiref shell that is.  The same things apply to a mangled version of the root @class attribute ("topic/topic reference/reference apiref/apiref").  I can imagine closed situations such as a tightly-coupled CMS where it is understood that "apiref" means "this particular apiref here", but in the wider world of interchange—one of the purposes of MIME—this information is useless and possibly misleading.  (This goes for any specialization, not just a fictitious one like "apiref".  Re-read this paragraph with "task" instead of "apiref".  Only "topic" and "map" are really sacred, and I'm not even certain of that with DITA 1.2 constraints in the picture.)

To be unambiguous you'd need to specify the public or system ID.  Any less seems to be just enough information to be dangerous, but not enough to be authoritative.  (And if applications end up not trusting the type parameter and gleaning the information from the contents anyway, is there any point in having it?)

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

I'm ambivalent about this, but I wanted to mention two more things that might not have been considered.

1. This is by necessity going to need to be a flattened version of the (DITA 1.2) navtitle.  If the navtitle has nested <b> or <codeph> elements then this information isn't going to survive.

2. Encoding and language matter any time you need to deal with human-readable text in a MIME type.  Are we going to mandate RFC2047 rules with respect to encodings, to encode a navtitle of "日本" as (say) "=?UTF-8?Q?=E6=97=A5=E6=9C=AC?="?  Because of Han Unification, even that might not be enough, so you'd also have to include "lang=ja" to ensure that the right glyphs get used.

This might be a bit more heavyweight than people wanted, but it's necessary if the information is going to be universally useful.

Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne

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