Re: XML libs (was Re: gconf backend)

[Havoc Pennington <hp redhat com>]

On Sat, 2003-09-27 at 18:42, Daniel Veillard wrote:
> > 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 ! 

At this point I think we're in agreement, if you're saying that as long
as I am using expat I'm sufficiently conformant.

Have a look at bus/config-loader-expat.c in dbus; is D-BUS XML compliant
in its XML loading using expat in that way? It only handles doctype,
elements, attributes, and content in the application code. If expat is
doing anything else behind the scenes or handling namespaces or PI or
includes or whatever then those things are handled, if expat isn't doing
them automatically then they are not handled and despite using expat the
app isn't compliant with the XML spec.

The subset of the expat API that I'm using there is basically all I'd
ever expect to use for the kinds of files I've written parsers for.
Malcolm may well be right that office apps are different.

Well, I'd add one more thing that I've used which is the "passthrough"
feature in gmarkup; it simply gives you a literal piece of text to be
resaved at a given point which can be used to preserve PI and comments.
Doing this as a more complex PassthroughNode opaque type rather than a
string would probably be sane and let you make it actually safe with
real XML.

>    - 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. 

Right, so these are the things I want to see in an ideal API. I believe
the very basic expat API I used in dbus, or a slightly larger
gmarkup-like API, would already include all these things.

Once I have those things I care about implementation issues; error
handling, code size, and so forth.

> 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.

Don't worry, I'm not going to try ;-)

> > > <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/>

If you must ;-) Link to the d-d-l threads on the UI for it, that will
keep people busy. ;-)

Havoc