Re: XML libs (was Re: gconf backend)

[Jody Goldberg <jody gnome org>]

On Sat, Sep 27, 2003 at 07:51:28PM -0400, Daniel Veillard wrote:
> On Sat, Sep 27, 2003 at 04:28:11PM -0400, Havoc Pennington wrote:
> > 
> > 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
> 
>   No and that is a big mistake you're making. Example: you don't have to 
> know about entities at the user level for those apps, you just let the
> parser do the work for you. You won't even know that they have been there.
> But if you ignore them at the lib level, you loose the data.

You can only get away with that when the data sizes are small, and
processing times are insignificant.  As the amount of data scales
the application needs more and more control over what is happening.

As an example.  In most instances applications do not need libxml to
generate their XML.  The app is in control on what is being
generated, and spewing a DOM tree is total overkill.  Gnumeric's
default xml exporter gets hammered this way on large files.  Four
times base representation memory usage is lethal for 100 Meg
workbooks.  This is why I have the ultra simple printf style
wrappers in libgsf.

On import similar issues arise.  The overhead of DOM and even
xmlreader are significant, which is why I had to whip up the trivial
little namespace supporting SAX wrappers for gsf.  We'll see if
conglomerate can adopt them, which would force the addition of
entities.

Another area where libxml could really assist its users would be a
set of canned conversion routines.  Applications all end up
replicating load/store operations on
    bool
    int
    float
    enum
    binary blob

Throwing in a set of those for content and attributes would go along
way to making things simpler out of the box.