[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: