Re: XML libs (was Re: gconf backend)

[Havoc Pennington <hp redhat com>]

On Sun, 2003-09-28 at 01:09, Malcolm Tredinnick wrote:
> Most of the examples you cite are pretty trivial uses of markup for
> which pretty much anything will work. So using XML is a good idea for
> those, since you get simple start / end markup that everybody kind of
> understands. GMarkup is kind of appropriate for that stuff, but it does
> have the drawback of enforcing simplicity on these files, since you
> cannot become too complex or the parser becomes catatonic.

Again, don't get stuck on gmarkup. I started the discussion by outlining
an ideal XML parser from my point of view, and unlike gmarkup it is a
real XML parser, at least to the extent that it can be without doing
things like loading URIs or validation.

> However, "office documents" is the odd man out (a separate category and
> a BIG one).

Totally willing to buy that.

> > But the XML usage in GNOME isn't handling DTD, PI, namespaces, etc.
> > Even when using libxml, the apps are just ignoring those features,
> > except when libxml automates handling them. Apps are just assuming the
> > gmarkup-like subset and ignoring everything else.
> 
> Some apps are indeed doing this. I wish you would not keep generalising
> this to every "GNOME" (man I hate the word -- it's too all-encompassing)
> application, though. And in case that sounds too strong, most of your
> comments, Havoc, are based on working on a particular set of
> applications -- it's a pretty impressive set, but there are applications
> that do use the full facilities of XML. People working in other areas do
> require the extra functionality.

Sure, I buy that. But they are apps that are about documents. For my
core-ish desktop component apps, my priorities are robustness, good
error messages, size, and other implementation issues; and not having to
read and understand a big pile of specs. ;-) 

> What this (and some of your other posts in this thread) seem to be
> saying is that we need an education program here. Application developers
> need to know which bits they can safely ignore and which bits should
> result in the application gracefully failing (*not* ignoring -- then
> we're back in airline checklist territory).

Once people have to read the docs you've already lost on an important
level. Yes I know people have to read some docs sometime, but any given
person only reads half the docs they ought to read.

APIs that simply force you to do everything you need to do, by having
the required information as mandatory arguments and puking if it's not
provided, or making you provide a callback for everything that matters,
or whatever, are better than docs.

The "there's only one way to do it" principle is a big win here as well.
One worry I have about this whole discussion is that it could lead to
more API in libxml2, and I'm not sure this is a good idea.

Havoc