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

["WebShark" <webshark ono com>]

----- Original Message ----- 
From: "Havoc Pennington" <hp redhat com>
To: <veillard redhat com>
Cc: <desktop-devel-list gnome org>; <xml gnome org>
Sent: Sunday, September 28, 2003 11:13 PM
Subject: Re: [xml] Re: XML libs (was Re: gconf backend)


> 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
>
================================
http://www.ansx.com