While a mime type can define a fragment identifier syntax,
there is always the question of what tools will recognize and implement that
fragment identifier syntax. Presumably, in the DITA case, it will just be
DITA tools which already recognize the syntax. So defining a mime type
specific fragment identifier syntax does allow us to say our href values are
true and official URIs, but it doesn't change too much in practice. (I
don't see the argument as either strongly for or against whether we should
define a dita mime type.)
Using application/dita+xml to allow tools to recognize dita
content sounds like a benefit. Again, though, you have to ask what tools will
actually access the mime type and recognize--and do something special--with the
dita mime type. The answer again is just dita tools which already
recognize dita content. So the only benefit might be making it a bit
easier for such tools to know they have dita without looking inside the
content.
But note that one can get a mime type only from mime
headers, and one has mime headers for a file in only rare cases in practice (and
half the time when you do have them, they are wrong or incomplete). The
rest of the time, tools guess mime type by looking at the file extension or
inspecting the content, and this can and is already done.
So defining a mime type probably has only a minor benefit
in practice.
I would counsel against trying to define multiple mime
types. Given the small benefit of mime types in general, if we try to get
too complicated here, we'll pretty much guarantee that there will
never be two fully interoperable implementations, and I don't see the
benefit of multiple mime types.
paul
From: Erik Hennum [mailto:]
Sent: Thursday, 2008 March 27 18:47
To:
Subject: [dita] mime type for
DITA?
Hi, Technical Committee:
Returning to an old question, should the
committee take a position with respect to a mime type for DITA?
http://lists.oasis-open.org/archives/dita/200408/msg00055.html
A
DITA mime type would let tools declare and recognize DITA content in HTTP
headers, email, and so on without actually inspecting the content. As I
understand Paul's note, a mime type would also provide a basis for defining
the DITA reference syntax within URI standards:
http://lists.oasis-open.org/archives/dita/200705/msg00040.html
One
might expect DITA to have a mime type similar to application/dita+xml
following ordinary practice for XML vocabularies:
http://en.wikipedia.org/wiki/XML_and_MIME
DITA
is an architecture, however, not a vocabulary. Section A.14 in the relevant
RFC suggests that an extensible architecture should prepend qualification
levels:
ftp://ftp.isi.edu/in-notes/rfc3023.txt
Applied
to DITA, that would seem to call for a mime type that separates the
declaration of the vocabulary (as defined by the shell for the document type)
from the DITA architecture from the XML architecture.
An application
that recognizes a document type can process any document that generalizes to a
valid instance of the recognized document type. Because of shell pluggability,
however, the mime type alone can't reasonably provide a basis for determining
the compatibility of a document type accepted by an application with the
document type of the supplied document. (The mime type for the document type
would have to encode the modules and ancestor modules included by the shell,
effectively cramming the value of the domains attribute into an
identifier.)
A reasonable compromise might be for the mime type to
identify only the base vocabulary. (That compromise also acknowledges the
impracticality of registering all DITA shells as mime types.) Applications
would have to inspect the domains attribute in the content for more specific
evaluation of acceptability. This approach avoids creating a legacy that would
have to be accomodated if future work solves the document type compatibility
problem some other way.
In summary, this approach would introduce two
fundamental mime types for topics and maps:
application/topic+dita+xml
application/map+dita+xml
Because the
DITA values file isn't specializable (doesn't provide the architecture
attributes), their mime types should identify the XML vocabulary but not the
DITA architecture:
application/ditaval+xml
Hoping that's useful,
Erik
Hennum
