Re: XML libs (was Re: gconf backend)

[Daniel Veillard <veillard redhat com>]

On Sat, Sep 27, 2003 at 04:38:02PM -0400, Havoc Pennington wrote:
> On Sat, 2003-09-27 at 15:35, Daniel Veillard wrote:
> >    Let me take an example. We use GNOME, on X-Windows, usually on a
> > local station or from a box on the LAN. Well we could trimm down the
> > TCP support and get X to attack at the UDP and have interesting performances
> > and lightweight RTT latencies. And we nearly never have really an use
> > for full TCP when running GNOME applications. Still we use TCP, even
> > on the local host. To me the parallel with XML subset versus full XML
> > is similar. There is a time were you forget about the implementation detail
> > of a comodity layer and just use What's There.
> 
> The problem is that to do this we have to make apps Just Work without
> having to understand XML in detail, just as I can write network code
> while having zero understanding of the TCP stack. TCP is just a byte
> stream to me. In the same way XML should just be a tree of elements,
> attributes, and content with some doctype; deriving from some single
> block of bytes the app obtained standalone. At least, for the apps I'm
> writing that's my experience.

  Yes and that's fine. Just like using 20% of the features of TCP is just
fine for most apps. The XML parser libraries, be it expat or libxml2
will take care of most of the annoying work needed to get things to 
a reasonable simplistic view without forcing the client to go into
the details. But you know they are gonna do it right ! 

> If someone has to understand XML in detail to write a compliant app,
> they almost certainly won't write a compliant app, because the XML spec
> is huge. It is probably a failing of the XML specification that it is
> too hard to write a compliant app and that compliance seems to require
> doing things that don't always make sense, like handling multiple files.

  You're mixing:
    - making use of all the features
    - being able to handle all the features
 the apps don't have to use all the features. But they should use a 
conformant library to avoid mishandling of data. Today if someone
starts to hack some gconf back-end file to use entities to avoid duplicated
strings or reflect system wide options, libxml2 and expat would handle
that transparently, gmarkup would fail to process them correctly. Still
taht would be a perfectly correct change from an XML point of view.

> I agree that there's huge value to having files that can be manipulated
> by standard tools, at the same time full XML compliance seems pretty
> much impossible for anything short of a web browser.

  You're making a wall out of block of bricks.
Your application doesn't have to know about the intricacies of XML
precisely because the parsers knows hoe to handle them. Encoding,
DTD, entities, those can be processed underneath and will in most
case, giving back a simpler API to a relatively complex framework.
There are 6 things you must know about:
   - namespaces
   - element
   - attributes
   - text content
   - processing instructions
   - comments.
 namespace are syntactic sugar to build complex document. You probably
don't need them in most case, if you see some you don't expect ignore
or halt depending on your processing model. the 3 next are your basic
blocks, the 2 lasts are thing you will usually ignore at the application
level. But between the flow(s) of byte and that view the parser must do
a lot to be conformant. Don't try to replace it, unless you have a lot
of time in your hands to get something conformant.

> I don't know what to do about that; in the meantime I just use the
> simplest possible solution for each situation and hope someone smarter
> will fix the problem.

  there is no need to be "smart" most of the complexity is removed
by the parsers.
  Seriously if you're scared by XML the last thing to do is to try 
to build your own framework to handle it, believe me :-)

> > <note> I would love to see the system tray implementation debugged and
> > integrated as maintained APIs in the toolkits for example ;-) </note>
> 
> As would I, unfortunately the spec and implementation are both totally
> screwed up. ;-)

  Can I quote you on the bug reports I get <grin/>

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/