Re: Broken i18n and the new UI handler.

[Daniel Veillard <Daniel Veillard w3 org>]

  Hi Havoc,

> I don't mean that libxml or xmlNode is large and error-prone for an
> XML node, I mean it's large and error prone to store some other kind
> of data.

  doohh, okay ...

> For example in the GConf backend I could store stuff internally as:
> 
>  struct _GConfThingy 
>  {
>    gchar *key;
>    GConfValue *value;
>    gchar *schema_name;
>  }; 
> 
> or something like that. For efficiency reasons (speed, not memory) I
> instead store the xmlNode tree. However, xmlNode is clearly larger than 
> struct _GConfThingy above,

  :-) no discussion about this !

> and also a good deal harder to use. Which
> resulted in buggier code than I would have had with a task-specific
> data structure.
> 
> The reason I store the xmlNode tree is to be able to quickly save at
> any time without having to build the tree. I could have avoided saving
> the tree with some cost in time it takes GConf to sync to disk.

  Okay 

> So, I think you misinterpreted what I was trying to say, I am just
> saying that making people use the raw xmlNode instead of a simpler
> data structure designed for the task is not a very nice API.

   yes, the duality between the "DOM tree" which is actually a full
XML Information Set http://www.w3.org/TR/xml-infoset (a bit more actually)
and the kind of data structures application needs is one part of
the XML usage which is hard. Unless one just want to manipulate an
XML tree it is hard to really enjoy the tree produced by libxml. And
as soon as one duplicates the information one need to maintain the
coherency between both which is a mess ... I haven't found any way
to solve this problem.

> There is also some value in building an abstraction barrier between
> the menu API and the exact XML DTD and parser being used, I think.
> That gives you a lot more future flexibility.
> 
> >  - while we are speaking about size, what is the largest input you
> >    envision to use in GMarkup ? Did you made any serious estimate of the
> >    memory needed by the equivalent libxml output before writing your
> >  own ?
> 
> GMarkup wasn't written to be smaller than xmlNode (though it is, just
> because it doesn't support many XML features). The point of GMarkup is
> mostly to just be in the GLib style and small enough to go in GLib.

  So it's mostly a (shared) library size issue...

> I actually think a full XML parser could be small enough (remove some
> of the addons such as nanohttp and xpath, etc.) - but I'm not sure
> it's worth doing that given that we already have libxml. I don't

  It may be worth splitting libxml into more than one shared library,
I'm not opposed to this at all ... Problem is that the entity resolution
may need the HTTP or FTP access and I don't know how to load them only
when needed at runtime (feasible, iconv works this way, but portable ?)
  Actually libxml configure allow to remove all non-core options

> personally care to maintain such an alternative XML parser at least.
> So since that won't happen GMarkup will have to do.

  But make sure it's 100% XML ... 

> >  - How do you intent to handle I18N and L14N issues in GMarkup ?
> >
> 
> GMarkup just loads and saves UTF8, and that's it.

  Well humm... XML requires UTF16 support, but it's not widely used on
linux ...

> > So i understand the reasoning behind GMarkup. But don't associate it
> > with XML it's not designed for this. If I had time I would spend the
> > 2 hours needed to make a SAX backend generating the same data
> > structures as GMarkup.  It would be a good way to learn what are the
> > differences and provide a reasonable way to compare both on real
> > stuff (and see if a fallback is possible for apps who may grow their
> > usage of GMarkup beyon the scope it was designed for).
> > 
> 
> If you have time to look at GMarkup and help ensure it is a genuine
> XML subset, that would be a very good thing. As long as it only saves
> valid XML, people can easily upgrade to libxml in the future.

  I don't really have much time, I should spent some anyway. Did you
made a list of the specific productions of the XML specification you 
do not support ?


Daniel

-- 
Daniel Veillard w3 org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe