Mimetype names (Re: mimetypes for zipped files)

[Marc Mutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 09 April 2002 23:06, Nicolas Goutte wrote:
> I regret that this discussion does not happen on one of the two koffice
> mailing lists but here on kde-code-devel. Well...

If you make sure my post gets through the moderator, I can read them via the 
uslinuxtraining.com anonIMAP feed...

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

Sorry, you shouldn't use the DTD URL as namespace URN, that is too strict. The 
namespace should be more stable and IMO only changed if the DTD breaks 
backwards compat in a major way.
  Having the year in the URL is a common convention. See
http://www.w3.org/TR/1999/xhtml, which is the URN for XHTML, IIRC.

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

You don't need the current version. The important bit is that you have this 
for _released_ versions. If you really want to update it for every change, 
use the webcvs URL. But the released versions shouldn't point to webcvs: 
Maybe KDE runs on arch or bitkeeper in a few years?

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

Typo.

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

Yes, but don't omit the version number.

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

I got the impression that much of the DTDs is shared between the KOffice 
applications. If that is so, one should draw on that and create a 
koffice-common.dtd and import it into the KWord/KSpread/etc. DTDs. The 
maindoc.xml document could then either specify the specialized DOCTYPE or use 
methods like XHTML1.1 to modularize the markup.

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

It's a URN. As such, it need not be a URL. It may be that XML namespace URNs 
are also something that can and should be registered with IANA, but I didn't 
get this far with reading while having the last reading-attack involving W3C 
recommendations ;-)

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

I'd be happy do the forms for people wanting to register something with IANA. 
But the people need to want it.

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

Very much agreed.

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

I thought the per-application mimetypes were actually only needed internally, 
to shove the data to the right part. The overall structure of KOffice 
documents seems to be identical. They just get different extensions. It seems 
unnatural to force a distinction where one isn't present.

Marc

- -- 
Marc Mutz <mutz at kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8s3Nq3oWD+L2/6DgRAkKDAJwNfH3Hcsc3KTW/tkcK8FhVjUyfawCg2dmO
v9LfSXQpusa1iAEKVImodm4=
=Xzr3
-----END PGP SIGNATURE-----