Re: XML libs (was Re: gconf backend)

Havoc Pennington wrote:

Keep in mind that I'm not really defending gmarkup.

On Sat, 2003-09-27 at 14:40, Daniel Veillard wrote:

 The problem then is that your subset is not someone else subset. Some
people tried that for a few years after XML got out in 98, they called that SML, it never worked. Why ? Because camp A don't want to see attributes,
camp B still need them, camp D don't care about PI or comments while camp
C absolutely want them, and there is the people who want DTDs anyway but
for ID/IDREF support...

Yeah, but we aren't trying to please the whole world. We have
essentially two use cases:

 - human-edited config files (/etc/foo.conf)
 - data files                (office documents, session state, gconf)

That covers 95% of GNOME I would say. It definitely covers what I've
used an XML-like format for (metacity themes, dbus config file, gconf
backend, menu system).

A significant amount of data files - both office documents and help documents in a desktop are going to need and rely on the XML really being XML, including all the things you are hand-waving away. Relatively soon now some of these would be using RelaxNG instead of DTD, and so on.

I don't know what other people want to do. I'm just saying what the
ideal library would be like from a desktop standpoint, at least the bits
of the desktop I've hacked on.

Maybe the other parts of the desktop have wildly different needs, I
don't know. I assume people will jump into the thread with their view.

There are other parts of the desktop that do indeed want full, "real" XML and not just a subset.

 libxml2 will garantee UTF-8 at the API level independantly of the
input encoding. If you don't ant to see entities, ask them to be sustitued.
If you see DTD, comments or PIs, simply ignore them. Still it's not a reason
to break conformance.

Having the app ignore those things is not different from having the XML
lib ignore them. Either way they are ignored. What I'm worried about is
bugs in apps where they crash when they get an unusual XML construct
they weren't expecting. That's why I don't think these things should be
in the API when it's avoidable.

It is different - a library that did so would have very limited applicability and will result in some applications linking to two libraries, one of which is just a subset of the other.

The fact is that whatever these features are supposed to do, your
typical desktop developer will not understand or want. And so they won't
handle it properly. So either we need the API to force you to handle it
properly, or the API in practice may as well not even have the feature.

A typical desktop developers approach to XML is probably similar to the approach to HCI related things back in the 1.x days.

You can't remap something like namespace, DTD, PI or comments to something which would be XML without them. Like asking a kernel to
remap the network layer on top of the disk driver because you don't
have a network card :-)

But the XML usage in GNOME isn't handling DTD, PI, namespaces, etc.
Even when using libxml, the apps are just ignoring those features,
except when libxml automates handling them. Apps are just assuming the
gmarkup-like subset and ignoring everything else.

s/apps/some apps/


- no I/O code of any kind; no error printing or LoadFile() or network

Okay what do you provide ? So taht also mean no catalog, so no DTD processing, probably no support for external parsed entities either...

That's right. The goal is just to parse a self-contained data stream.
Anything that starts to involve merging multiple streams from multiple
URIs is going to require the app to be much more sophisticated.
Well, at least for including subsnippets of the file itself from another
file (which would break gconf) or downloading remote URIs (which would
break metacity), for example.

This is just completely not true - except possibly the gconf bit, which depends on how its implemented.

- application can "throw" an error itself if it doesn't like the
  elements/content it sees

 I really don't see why , one of the nice thing of your pseudo API
taht everybody would love to use is taht your didn't specificedif it
was push or pull (i;e; who keep control of the I/O flow, and I know
people will want both).

If there's no DTD validation, the app is doing its own error checking.
Even if you had DTD validation, some things can't be expressed via DTD
so the app has to do some of the checking anyway. e.g. the DTD can't
express the possible values of the color attributes in metacity themes,
that can be "#RRGGBB" or "gtk:fg[NORMAL]" or some other stuff. So the
app needs to be able to throw an error like "invalid value for attribute
foo on line 23"

So use a RelaxNG schema? And I think you are a bit over-optimistic when it comes to document structure checking by apps - besides, its completely unneeded code.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]