[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] mime type for DITA?
Is there a specific use case that caused the issue of DITA mime type(s) to be raised again now?
At PTC/Arbortext we talked about having an official mine type for DITA objects about a year ago, but we’ve been able to get by without it quite nicely so far.
If we do try to get some sort of official mine type, I’d like to find a way that we could tell more than just that we have a DITA document. Ideally I’d like to know in order: 1. If we have a DITA document 2. If we have a DITA map, DITA topic, DITA ditabase, or ditaval document 3. What type of DITA document we have (topic, concept, reference, task, glossentry, map, bookmap, learningMap, …)
I’d need to go back and refresh myself on the details of mime type syntax, but I vaguely remember that there were ways to provide more detailed information without creating completely new mine types.
I agree with Paul that having an official mine type may not provide much additional benefit and so I’m not pushing for this myself, but if we do go forward I’d like to be able to get additional information beyond just DITA or not DITA.
And even if we don’t go forward with an official mine type, I’d like to somehow encourage CMS implementers to include this level of detail in the CMS metadata associated with a DITA object so that someone can use or get this information as they search or browse without having to open each DITA object each time.
-Jeff
From: Grosso, Paul [mailto:pgrosso@ptc.com]
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]