Re: XML libs (was Re: gconf backend)

[Havoc Pennington <hp redhat com>]

On Sun, 2003-09-28 at 02:00, Sander Vesik wrote:
> > That's right. The goal is just to parse a self-contained data stream.
> > Anything that starts to involve merging multiple streams from multiple
> > URIs is going to require the app to be much more sophisticated.
> > Well, at least for including subsnippets of the file itself from another
> > file (which would break gconf) or downloading remote URIs (which would
> > break metacity), for example.
> > 
> 
> This is just completely not true - except possibly the gconf bit, which 
> depends on how its implemented.

How is it not true? gconf clearly assumes its XML files are
self-contained in a single file, and metacity clearly assumes that
loading a theme is a fast nonblocking secure operation.

If handling full XML violates those assumptions, making those apps "XML
compliant" becomes either impossible or really damn hard. You for sure
aren't going to do it transparently in the library.

> > If there's no DTD validation, the app is doing its own error checking.
> > Even if you had DTD validation, some things can't be expressed via DTD
> > so the app has to do some of the checking anyway. e.g. the DTD can't
> > express the possible values of the color attributes in metacity themes,
> > that can be "#RRGGBB" or "gtk:fg[NORMAL]" or some other stuff. So the
> > app needs to be able to throw an error like "invalid value for attribute
> > foo on line 23"
> > 
> 
> So use a RelaxNG schema? And I think you are a bit over-optimistic when 
> it comes to document structure checking by apps - besides, its 
> completely unneeded code.

Argh, no. One of the key things for the code I've written is that I
don't want to deal with DTDs/schemas. Even if I had time to learn those
rather large specs in detail, I would still not feel confident that I
could write a fully robust schema that would give good error messages to
the user. While I am quite confident in my ability to write a C parser
for a color attribute - in fact I _have_ to write such a parser, and
making it report errors isn't very challenging.

I have to write code to convert the XML structure to my app data
structures, and that code may as well do the validation.

The value of a schema rather than doing it in code is that multiple apps
can share the schema, I would say. Which is nice, but has to be weighed
vs. the tradeoffs of inferior error messages and increased developer
knowledge required. You can always add the schema later, I usually get a
DTD eventually from a contributor.

By inferior error messages I mean something like "attribute doesn't
match regexp 'big scary regexp'" is worse than "attribute must have
format #RRGGBB or gtk:fg[NORMAL]" (pick many other similar examples,
browse metacity/src/theme-parser.c).

I simply can't bring myself to write nonvalidating C code, anyway. Even
if I had a schema I'm pretty sure I'd write all the error handling, I'm
just too paranoid to trust that the schema is fully robust.

Havoc