Re: [xml] Re: XML libs (was Re: gconf backend)

[Havoc Pennington <hp redhat com>]

On Sun, 2003-09-28 at 15:50, Daniel Veillard wrote:
> > I guess I'd say the current Reader API is fine as long as silently
> > ignore is the right behavior for those extra node types. I can easily
> > implement silently ignore in my app. But if the app should be throwing
> > an error or doing something else when it gets these nodes, I don't know
> > how/when/whether to do that.
>
>   Well, it's all your application business. If you can't handle them
> raise an error.
>  That mean a contract has been broken between the provider
> and the consumer of the information, while it still passes fine at the XML
> level. If you expect a color code and get a street address in the content
> of some tag you have the same problem. It's purely application logic.
> But it's not where XML conformance is defined.

At that point, the app is only using an XML subset, not XML. The
subsetting is on the app level rather than the library level but this
isn't relevant if you're just looking at the app's net functionality.

With NOCDATA, SUBST_ENTITIES, NONET and ignoring the extra nodes, the
app will handle pretty much the same XML subset exposed in the gmarkup
_API_ (not parser backend) or that I'm using from expat in
config-loader-expat.c.

Yes expat/libxml2 will handle more corner cases properly than gmarkup
_implementation_, and thus the subset will be strict rather than a
little fuzzy around the edges. That's good and I would prefer that.

But there's no advantage at all to the larger _API_ in expat/libxml2
*from the standpoint of an app using XML in this way*, vs. the gmarkup
_API_.

I think we probably agree on this point and already said it a few times,
but I just want to sum up. 

Where we maybe don't agree is that I think this makes it perfectly
reasonable to have a gmarkup-like API in a library with libxml2 or expat
as the backend. In other words, an XML-subset API is a legitimate thing
just as much as an XML-subset application is.

A library API can be designed to support a particular application of XML
and conceal some of the complexity of the XML specs.
I don't see why the conceal-XML-complexity/specialize-the-API step
always has to be in the app. I agree it may not be right in libxml2, but
I don't think it has to be in the app either.

I even thought of a name for the subset I repeatedly use, which is POD
(plain old data). POD-XML. ;-)

Havoc