Re: [boost] Proposal: XML APIs in boost

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-11-10 23:04:15

Graham Bennett wrote:

>>I wish people would stop being so parser-focussed. I reiterate: the
>>API I suggest is about manipulating a DOM tree. The fact that you
>>*might* want to construct it from an XML file by means of a parser is
>>almost coincidental.
> 
> 
> I agree that the way the DOM is created doesn't really have anything to
> do with a parser or anything else.  It's perfectly possible to put the
> DOM together any way you want.  I think people have expressed concern
> that the intention might be to ship the library with a libxml2 (or any
> specific parser) implementation for building the DOM from text, which I
> don't think would be a good idea.  I was suggesting that having a way to
> build the DOM from a standardised interface, like a reader, would be a
> way to separate these concerns.

Well, I seem to express myself poorly:
The creation of the DOM tree itself is only half of the story. You
also need to be able to traverse and process it, in a very domain-specific
way. That processing involves a lot of knowledge that would have to be
coded (XPath, XInclude, XPointer, ...).

So, when talking about 'backend' I'm not talking about a DOM factory,
but a DOM implementation.

I'm not sure how many people really are concerned about the libxml2
backend. One or two have voiced their opposition. It was not because
my specific choice of backend, but because the fact that it wouldn't
be an integral part of boost. That's the old 'Not Invented Here'
syndrom, and there isn't much to do about it. People will always
try to reinvent wheels. That's ok, as long as they don't hinder
others to use existing wheels.

And finally, I'm not too concerned about backend dependencies, as
the real point of the proposal is the API, not the implementation,
i.e. it must be possible to replace one backend by another. And
if people are dissatisfied with having an external library dependency,
they can 'easily' write a new implementation and throw that in instead;
the user mustn't be aware, or else the API design was a failure.

>>You still need to provide all the other missing bits, such as an XPath
>>lookup mechanism, XInclude processing, http support for URI lookup,
>>etc., etc.  I can't stress it enough: the parser is really just a tiny
>>bit of it all.
> 
> 
> Agreed that the parser is a small part, but so is the DOM.  All of the
> things you mention above can and should be implemented independently of
> a DOM model, IMO.

Why should they ? 'DOM' is exactly that: a specific 'model'. It's there
for a purpose, so other services can be hooked into it.

> Please don't think that I'm against a Boost DOM implementation, I think
> it's a worthy effort and what you have submitted is a good start.  I
> just think that a standardised reader interface is a much more important
> integration point than DOM, and I'm suggesting that it would be
> worthwhile putting effort into that area sooner rather than later.

Good. Interdependency between DOM and SAX / Reader aside, I understand
your point. I'm tempted to add an XmlReader to the library, as it would
be relatively simple to implement on top of the libxml2 API.
But for the sake of keeping the discussion focussed on the DOM API
I won't.
Let's start a different thread for other APIs. I agree that they would
be useful.

Regards,
                Stefan