Duality (was Re: gnome-config problems)

[Jim Pick <jim jimpick com>]

[s-expressions vs. HTML arguments deleted]

I've thought a bit more about the "duality" of representing stuff
using s-expressions, or by using SGML source and a DTD.

Both are good, and both work.  But I think it's easy to develop a
"rule of thumb" to decide which to use:

Lisp style s-expressions are very flexible, lightweight and easy to
parse, and easy to change around.  They're great when you need
flexibility, and will be changing the format lots.  They can be used
in a very structured manner too, if needed.  But they're best for
ad-hoc stuff.  Note: s-expressions aren't just for lisp, they're easy
to parse in any language, ie. 'C'.

SGML source and a DTD (Document Type Definition) are quite good at
representing structure inside "documents".  So if the file that you
want to parse looks an awful lot like a document, SGML is definitely a
good choice.  It's ok to trade flexibility for structure in this case,
because you don't want to be changing your structures often - because
then you've got to fix all those long-winded documents.

There's a real "duality" happening there.  You'll notice when you feed
SGML source and a DTD into the sp parser, it spits out s-expressions.
Vice-versa, you could use SGML expressions to mark-up a document,
providing you stuck to a certain pre-defined structure.

            SGML approach                S-Expression approach

   +-----------------------------+  +-----------------------------+
   |          Core App           |  |          Core App           |
   +-----------------------------+  |   (includes simple parser)  |
   |      SGML Parser & DTD      |  +-----------------------------+
   +-----------------------------+  |          Raw Data           |
   |           Raw Data          |  | (s-expressions, must match  |
   |    (SGML, must match DTD)   |  |       code in core app)     |
   +-----------------------------+  +-----------------------------+

It looks like the SGML approach has an additional level of
abstraction, but it's worth pointing out that the Core App in either
approach can additionally add several more levels of abstraction.

The system with the least number of levels of abstraction (could be
either one) is easiest to hack on (less files to hack on, less
mis-matched interfaces).  But more levels of abstraction are
beneficial when it comes to integration, code sharing, documentation,
learning curve, etc.

Other comments:

The current windows-3.1-style initialization files (in the .gnome
directory) are easy to understand, but they're going to be useless for
storing structured data.  They're fine for tag-value pairs though.

For many specialized applications (languages, for example), it's often
worthwhile to develop your own syntax and parsers, of course.

So:

I think it would be nice to develop an SGML/XML widget (perhaps based
on gtk-xmhtml) that could understand an arbitrary DTD.  Check out
QWeb, it already does this (it uses Qt though).  I think the Mnemonic
guys wanted to do the same thing.  There are quite a few other SGML
browsers out there too.  Microsoft is doing lots of work in this area
- they want to do all their dialogs via HTML/XML.

Personally, the source for most dialogs don't really look like a
"document" to me - it's probably more like a specializing programming
language.  That's the beauty of List/Scheme/Guile - you can get
something that is essentially a new language just by defining new
library functions.  You can do the same thing with SGML and a DTD, but
it's not as good of a match.

Cheers,

 - Jim

PGP signature