Mimetype names (Re: mimetypes for zipped files)

[David Faure]

On Monday 08 April 2002 20:00, Marc Mutz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 08 April 2002 14:56, David Faure wrote:
> > > [1] Unfortunately, last time I looked (a few months ago), the KOffice
> > > DTD's were not properly namespaced with something like
> > > xmlns:kword="http://www.kde.org/DTD/2001/koffice/kword-1.1.1.dtd",
> >
> > That's about adding one line at the top of the DTD, isn't it ?
> 
> Not really. My complaint about the use of XML in KOffice from back then still 
> holds, I guess. It's about first defining a location on www.kde.org where the 
> dtd's of releases can be kept. That one must not change in the forseeable 
> future. The above URN is just an example. The dirs should actually exist, 
> since it's common that the namespace URN is actually a URL where the DTD can 
> be fetched from.

Sure, I understood that the DTD must be downloadable from there ;)
Some questions: is it mandatory to have the year in it? If we have the version
number - the one of the DTD rather than the one of the application, in case the
DTD doesn't change between two releases - do we really need the year?
(For the number, I used 1.1.1 at first, but I'm going to use 1.1 and later 1.2 instead)

> <!DOCTYPE document-info PUBLIC "-KDE//DTD document-info 1.1.1//EN"
The "document-info" in the public ID is the name of the root element, right?
What's this public ID used for?

>   "http://www.kde.org/DTD/2001/koffice/document-info-1.1.1.dtd">
System ID. Ok. I managed to used QDom to add all those fields, will commit 2 helper
methods to KoDocument soon.
I wrote a DTD for document-info stuff too.

> <document-info xmlns="http://www..kde.org/DTD/2001/koffice/document-info">
Is this the URL of the DTD, or the URL of the directory containing it? In the examples
I found it's often a directory rather than a DTD URL, but I don't understand why...
Is this just like a namespace, whose value doesn't really matter in fact - but people
use parts of a URL in order to ensure its uniqueness?

> > > so registering a mimetype with IANA against a moving and undocumented (in
> > > the above sense) DTD would just result in the world laughing at us, so I
> > > gave up on it for the moment.
> >
> > "Moving" is always going to be the case.
> 
> Well, that's what the version information in the DOCTYPE is actually for, no?

Oh, ok. Then there's no problem. I thought you said it was one.

Thanks for the above explanations. The XML generated by KOffice will be more compliant
in the next release...

Since you seem to care about such compliance, why not do the same to the DTD for the XMLGUI?
That's a _lot_ of .rc files to change though.

> Yes, and only because we are Open Source, we are allowed to ignore and break 
> the standards, yes? Are we Microsoft or what?

Ok, you misunderstood my position on this issue. But I give up trying to explain it.

> I think IETF will have nothing against registering this as app/tar if someone 
> writes a RFC about it.

Sure - my point is that that "someone" hasn't stepped up yet. Please register
the 100+ mimetypes used in the opensource world (and not only), that nobody 
has registered yet, then rename all the mimetypes in KDE, Gnome and Apache,
then take care of the migration. I won't stop you from doing it, on the contrary,
I simply have other priorities.

> > Except that a KWord document was a tar.gz, and is very soon going to be
> > a zip file. It's not a raw XML file. Are you sure the +xml applies?
> 
> It applies for the maindoc.xml file, not for the tar/zip archive, yes. The 
> latter should probably simply be application/vnd.kde.koffice.

I don't really see why we need a mimetype for the inner components of a koffice
document. What we do need most, is a mimetype for the complete (tar/zip) document,
and that one has to be application-specific, otherwise we don't know which app to launch.
Hence it must be vnc.kde.kword (or vnc.koffice.kword), not just "koffice".

-- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today