Mimetype names (Re: mimetypes for zipped files)

Nicolas Goutte nicog at snafu.de
Wed Apr 10 21:02:25 BST 2002


On Wednesday 10 April 2002 01:04, Marc Mutz wrote:
> -----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...


For mailto:koffice at kde.org there is no moderator, however it is the more user 
oriented list.

For mailto:koffice-devel at kde.org it is David Faure who is the moderator.

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

Yes, for W3C it is understandable, as they have many DTDs per year. But for 
KOffice, I am not sure at all.

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

Ah, you mean that for KOffice CVS HEAD we should use the defintive URL for 
KOffice 1.2's DTDs.

I had not thought about this. Sound fine with me, as we can copy for each Beta 
version the DTDs from the CVS.

(To be clear: when I write CVS, I mean the non-ACL part of it.)

> use the webcvs URL. But the released versions shouldn't point to webcvs:

> Maybe KDE runs on arch or bitkeeper in a few years?
Yes, sure!

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

Yes, it would be better! ;-)

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

No, perhaps only KPresenter and KWord have some common parts. The rest is 
pretty different as far as I know.

> 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

Ooh! That is the subtlety that I had not understood between URN and URL.

Yes, then it is better that it would not be an URL.

> 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 ;-)
>
(...)
> >
> > 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.

Thank you for the offer!

>

(...)

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

Even if the external structure (now .tar.gz, in future .zip) is the same, we 
need to know the type before calling one of the KOffice programs. We do not 
have a loader that first load and then dispatch.

>
> Marc
>
> - --
> Marc Mutz <mutz at kde.org>
(...)

Have a nice day/evening/night!




More information about the kde-core-devel mailing list