Re: XML libs (was Re: gconf backend)

[Sander Vesik <Sander Vesik Sun COM>]

Havoc Pennington wrote:
> Hi,
>
> Keep in mind that I'm not really defending gmarkup.
>
> On Sat, 2003-09-27 at 14:40, Daniel Veillard wrote:
>
> >  The problem then is that your subset is not someone else subset. Some
> > people tried that for a few years after XML got out in 98, they called 
> > that SML, it never worked. Why ? Because camp A don't want to see attributes,
> > camp B still need them, camp D don't care about PI or comments while camp
> > C absolutely want them, and there is the people who want DTDs anyway but
> > for ID/IDREF support...
>
>
> Yeah, but we aren't trying to please the whole world. We have
> essentially two use cases:
>
>  - human-edited config files (/etc/foo.conf)
>  - data files                (office documents, session state, gconf)
>
> That covers 95% of GNOME I would say. It definitely covers what I've
> used an XML-like format for (metacity themes, dbus config file, gconf
> backend, menu system).

A significant amount of data files - both office documents and help 
documents in a desktop are going to need and rely on the XML really 
being XML, including all the things you are hand-waving away. Relatively 
soon now some of these would be using RelaxNG instead of DTD, and so on.

> I don't know what other people want to do. I'm just saying what the
> ideal library would be like from a desktop standpoint, at least the bits
> of the desktop I've hacked on.
>
> Maybe the other parts of the desktop have wildly different needs, I
> don't know. I assume people will jump into the thread with their view.

There are other parts of the desktop that do indeed want full, "real" 
XML and not just a subset.

> >  libxml2 will garantee UTF-8 at the API level independantly of the
> > input encoding. If you don't ant to see entities, ask them to be sustitued.
> > If you see DTD, comments or PIs, simply ignore them. Still it's not a reason
> > to break conformance.
>
>
> Having the app ignore those things is not different from having the XML
> lib ignore them. Either way they are ignored. What I'm worried about is
> bugs in apps where they crash when they get an unusual XML construct
> they weren't expecting. That's why I don't think these things should be
> in the API when it's avoidable.

It is different - a library that did so would have very limited 
applicability and will result in some applications linking to two 
libraries, one of which is just a subset of the other.

> The fact is that whatever these features are supposed to do, your
> typical desktop developer will not understand or want. And so they won't
> handle it properly. So either we need the API to force you to handle it
> properly, or the API in practice may as well not even have the feature.

A typical desktop developers approach to XML is probably similar to the 
approach to HCI related things back in the 1.x days.

> >  You can't remap something like namespace, DTD, PI or comments to 
> > something which would be XML without them. Like asking a kernel to
> > remap the network layer on top of the disk driver because you don't
> > have a network card :-)
>
>
> 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.

s/apps/some apps/

[snip]

> > > - no I/O code of any kind; no error printing or LoadFile() or network
> > >   access
> >
> >   Okay what do you provide ? So taht also mean no catalog, so no DTD 
> > processing, probably no support for external parsed entities either...
>
>
> 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.

> > > - application can "throw" an error itself if it doesn't like the
> > >   elements/content it sees
> >
> >  I really don't see why , one of the nice thing of your pseudo API
> > taht everybody would love to use is taht your didn't specificedif it
> > was push or pull (i;e; who keep control of the I/O flow, and I know
> > people will want both).
>
>
> 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.

[snip]

> Havoc