Mimetype names (Re: mimetypes for zipped files)

Tue Apr 9 22:06:51 BST 2002

I regret that this discussion does not happen on one of the two koffice 
mailing lists but here on kde-code-devel. Well...

>-----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",

Where do you see the advantage to have the year in the path?

>>
>> 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.

I had also not liked it. However, I have not yet found any way how the current 
version in CVS could be pointed at (without having CVS HEAD)

>
>A .kwd that I have here expands to maindoc.xml and documentinfo.xml.
>documentinfo.xml reads:
><?xml version="1.0" encoding="UTF-8"?><!DOCTYPE document-info >
><document-info>
> <log>
>  <text></text>
> </log>
>...
>
>First, the DOCTYPE has neither SYSTEM nor PUBLIC specifiers in it. I think 
>this is not even well-formed XML, much less valid. I'd suggest PUBLIC 
>specifiers like:

It is valid XML. In point [28] of section 2.8 of the XML specification, it is 
writen that the external identifier is optional. "xmllint --valid" finds it 
valid too.

><!DOCTYPE document-info PUBLIC "-KDE//DTD document-info 1.1.1//EN"

Why it is "-KDE//..." and not "-//KDE//..." ? The mini-tutorial in XHTML 
Modular tells that it is in the form "-//Company//Some Text//EN"

Additionally, I would thing that something like "-//KDE//DTD KOffice Document 
Info//EN" would be clearer.

However, for the other we can have something like "-//KDE//DTD KWord Syntax 2" 
or "-//KDE//DTD KWord 1.2"

>  "http://www.kde.org/DTD/2001/koffice/document-info-1.1.1.dtd">
>
>
>Then the document-info element misses namespacing. Using common tag names 
>like 
><text> without putting them into namespaces is just like defining a global 
>text() function in a c library. So there should be:
><document-info xmlns="http://www..kde.org/DTD/2001/koffice/document-info">

Here I have a question: where does the name space has to point?

I do not find the XML name space specification very clear if it should be a 
real URL/URN or if it can also be a fake one.

>...
></document-info>
>
>
>> In that case it's rather easy to do, please provide patch or detailed
>> instructions ;)
>
>Detailed instructions are above. ;-)
>
>> > 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.

Any change of syntax is another DTD.

That is why I always tried to increase KWord's syntax number. We have not the 
same DTD, so it is not the same syntax anymore.

>
>Well, that's what the version information in the DOCTYPE is actually for, no?

Yes!

>
>> Unless someone can tell in advance which features are going to go into
>> KWord for the next 15 years...

You do not need. In 15 year time, you will just have many DTDs.

>
>That's not neccessary. Look what W3C does with XHMTL and you know what KDE 
>should do with the XML formats it defines. Just adjust the version number in 
>the DOCTYPES of generated files and respect them on reading files, so you can 
>be backwards-compatible without guessing. ;-) And upload the DTDs of released 
>software.
>
>> > Seeing the vast number of obsolete (since at least
>> > 1996) "x-" mimetypes being added to kdelibs/mimetypes, I also get the
>> > impression that the KDE project isn't interested in registering it's
>> > mimetypes with IANA under e.g. the vnd.kde.* tree.
>>
>> Right (see my last answer on the xdg-list, BTW I think you should subscribe
>> there if you're not, since mimetype stuff was recently discussed there).
>> Even though vnd.*.* is what the iana recommends, everyone (and by that I
>> also mean apache, gnome, etc.) still uses x-. I'm not only talking about
>> the KDE mimetypes, but also about image formats, text formats etc.
>

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

The problem is that people need to be informed.

Not everybody is easy at reading standards. And you need enough time to read 
(and understand) them 

>
>   For convenience and symmetry with this registration scheme, media
>   type names with "x." as the first facet may be used for the same
>   purposes for which names starting in "x-" are normally used.  These
>   types are _unregistered, experimental_, and should be used only with
>   the active agreement of the parties exchanging them.
>
>   However, with the simplified registration procedures described above
>   for vendor and personal trees, it should _rarely, if ever_, be
>   necessary to use unregistered experimental types, and as such use of
>   both "x-" and "x." forms is _discouraged_.
>
>Getting our stuff registered with IANA is not only for the record, but also a 
>sign of professionalism. Since 1996, registering mimetypes under vnd. is so 
>dead easy that there is _no_ excuse to proceed with using x-. It's not about 
>the x- in particular that I keep on ranting here, but simply the fact that x- 
>mimetypes cannot be registered with IANA and vnd. namespaced types have the 
>lowest barrier to registration (ie. they will _always_ registered in 
>practice). We could also try to get application/koffice, but that needs a 
>full-blown rfc being written.

I am sorry, but many people do *not* like formulars and are not easy with such 
forms (some people even dislike bug tracking system for that reason.)

>
>> Changing
>> this now, and in KDE only, would bring much trouble (user configuration,
>> compat issues, etc.).
>
>See that idea about aliases in my last post to this thread. They're needed 
>anyway.

Yes, without aliases we can forget to change any mime type. And it will also 
help for distributions that cannot help themselves but to rename mime types.

>
>> And also, this vendor-based approach doesnt' really
>> work in the opensource world. Who's going to be the "vendor" for
>> application/x-dvi
>
>vnd.knuth.dvi ;-)
>But I see no problem to get this registered as app/dvi, though it needs 
>someone familiar with the format to assess the security considerations.
>
>> ? For application/x-tar?
>
>I think IETF will have nothing against registering this as app/tar if someone 
>writes a RFC about it.
>
>> eps?
>
>application/encapsulated-postscipt. app/postscript was registered in rfc2046 
>without Adobe.
>
>> cpio? xpm? etc. IMHO it's
>> much more practical to keep using x- stuff in the opensource world, and let
>> commercial people register their vendor-namespaced mimetypes. For KDE/Gnome
>> specific mimetypes this argument doesn't apply, obviously, we could use
>> vnd.kde.*, but for consistency everything uses x- currently.
><snip>

I do not think that we absolutely need to re-define every mime type used. We 
could start by re-defining the pure KDE ones.

>
>Not for consistency, but for saving five minutes of work (for filling out the 
>IANA template) and a bit of thinking when choosing a new mimetype.

I am sorry but filing in a formular in English is more than five minutes of 
work.

>
>I thought the standards compliance of OSS was higher than that of proprietary 
>software. :-(
>
>Ah, CUPS is a light in the dark (see attachment).
>
>> > E.g. KWord's mimetype should have been application/x-vnd.kde.kword+xml
>> > from the moment on where it was first used, and after registration with
>> > IANA and _before_ the first stable release,
>> > application/vnd.kde.kword+xml. See rfc2048 and rfc3023 for more.
>>
>> 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 think that an unique mime type for KOffice files is not enough. We need one 
mime type per application. As for mime types for the XML file itself, I do 
not see the need. I think that we can live with application/xml there.

>
>Marc

Have a nice day/evening/night!