[Glade-devel] Why libxml2 and not GMarkupParser?

[James Henstridge]

On 13/01/04 04:47, Tim Müller wrote:

> Attached then yet another patch against libglade-2.0.1 [*] that 
> introduces a
>
>--without-libxml2 option for ./configure. 
>
>The code has been re-arranged to be as little invasive as possible 
>(introducing some inefficiencies due to the need to wrap the attributes 
>arrays into the format used by libxml2's sax parser though).
>
>I think it is worth mentioning that the core difference between using libxml2 
>and GMarkupParser in glade-parser.c comes down to probably around 50-100 
>lines of simple and straight-forward code now. Most of the patch deals with 
>decompressing gzipped .glade files/buffers. Which means that either way no 
>one is "betting the whole farm" on anything here  :-)
>
>Given the lack of enthusiam here for my idea to use GMarkupParser instead, I 
>am not sure whether it's a good idea to fold this stuff into the code tree, 
>especially given that it's only been tested by me so far. But if anyone wants 
>to play around with it, here it is.
>  
>
Hi Tim,

Sorry for not replying to your earlier post.  Before applying a patch 
like this, I'd want to get some agreement on what subset of XML we 
should support.

GMarkupParser only accepts a small subset of valid XML files.  Is that 
subset good enough?  Some of the things not supported include:

    * files in encodings other than UTF-8
    * entities other than >, < and &
    * anything related to DTDs ...

What limitations do other glade file consumers have?  What features do 
glade file producers produce?

Libglade doesn't currently do all the processing it could (eg. 
processing of the internal DTD subset, and expanding custom entities, 
which some people have asked for), so I am not opposed to defining a 
subset that glade files need to conform to in order to interoperate.

I just don't want to end up defining this subset as "what libglade accepts".

James.

-- 
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/