Re: [dita] mime type for DITA (2)

[Deborah_Pickett@moldflow.com]

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
Deborah_Pickett@moldflow.com