Re: (Possible) menu code rewrite
On Tue, 2002-07-16 at 18:08, Wichert Akkerman wrote:
> Previously Chris Lawrence wrote:
> > - Complete backward compatibility with existing menu entries.
> > - Built-in support for conversion to .desktop files for KDE and Gnome.
>
> If you use an XML syntax you could trivially generate them using XSLT
> in a simple portable manner..
Agreed. Here are some other good reasons to use XML (this is from
http://people.debian.org/~walters/debian/why-xml.txt, which I wrote for
the people who were going to ask me why the new dpkg-source uses XML for
some new [optional] files).
* Supports comments in the control files.
* Has a standard way of specifying what character set the input data
is in (and has a nice default of UTF-8). As Debian grows to be more
international, our tools have to handle this.
* Has a standard way of writing escaped characters, so people in a
non-UTF-8 enabled environment can still put UTF-8 data in the file.
* Is very extensible, so we could support markup in Description:
fields, for example. Instead of everyone writing a list using their
favorite ASCII character (e.g. '*', '.', '-'), we could add elements
like <ol> and <li> from HTML to the Description field, and user
agents could display it as they like.
* Can handle complex data structure much more easily than a
rfc822-style format. A good example is Build-Depends, with
arch-specific dependencies.
* Can handle spaces in data very easily. Unix kernels have no problem
with spaces in filenames; we shouldn't write braindamaged tools and
formats which can't handle it, or at least only have an ad-hoc
ill-specified way of handling it. An upstream maintainer should be
able to name their program "foo bar-1.0.zip", and distribute it that
way. Other systems such as Windows and MacOS handle this just fine.
* Has a lot of high-performance parser implementations available, for
many different programming langugages.
* Has small-size parser implementations available.
* Allows for automatic structure verification (via a DTD). Thus, we
could easily catch errors like a malformed Build-Depends.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: