Re: my worry about the recent libxml change
- From: Daniel Veillard <veillard redhat com>
- To: Owen Taylor <otaylor redhat com>
- Cc: Daniel Veillard <veillard redhat com>, gnome-hackers gnome org
- Subject: Re: my worry about the recent libxml change
- Date: Sat, 24 Mar 2001 15:35:01 -0500
On Sat, Mar 24, 2001 at 02:43:17PM -0500, Owen Taylor wrote:
>
> Daniel,
>
> I have to agree with Maciej here.
>
> Once you've made a stable release of a library, then the proper
> behavior of the library is not determined by what is correct, or
> even what is documented, but by what is being used by the
> applications out there.
>
> This puts the burden on a library maintainer to try and make sure
> people don't use things they aren't supposed to, before they
> release:
>
> - With documentation
> - By making the library as strictly validating as possible
>
> But you can't increase the strictness after you release. If you
> release a SAX parser that allows non-closed end-tags, and people
> start using it that way, you can't say later "but that isn't
> valid XML, and this is an XML parser!" and change the library,
> however true the statement is.
Then Nautilus should link against the broken library, this should
not prevent others from using a decent tool.
> Now, you can, of course, augment the API to allow calls:
>
> - "Strictly validate end tags for SAX"
> - "Make sure that the internal encoding is always UTF-8"
>
> But the default mode of operation HAS to be the one that is
> compatible with the applications out there. Breaking existing
> functioning apps is something to be done only under the most
> extreme circumstances. (*)
This augmented API exists, is called libxml2 and people are forbidden
to link against it, only if they use Gnome 1.x . At that point they have the
right to consider that 1.x is not an API you want to develop against and
use whatever widget set which will allow you to use a proper parser.
I could of course sacrifice another couple of days to have both unclean
and clean behaviour available ... I need to gauge if I should loose more
time on the issue. The fact that db2html2 worked for the existing set of
docs is in itself a real miracle (well I assume actually they constrained
the doc authors until this passed abusively through libxml1) and whatever
people can say about not changing the behaviour, I have told the authors
multiple time, 6 months ahead fo their first release that this should not
be done, would not work and was an unsupported use of libxml1. It's even
better than having documented it it was discussed directly with them and
they bypassed my point of view and the alternatives I suggested.
Another blunt view would be that Gnome 1.x team makes only libxml1.2.11
part of the officially sanctionned release and that people who don't care
about Nautilus but care about the validity of thir XML based apps switch
to libxml1.2.12 or libxml2 like the PLD people have already started to do
and it seems the Ximian people would like to do too. You will note that I
tried to stop both in the last 2 weeks, by yelling at the PLD people first
(sorry no archive but people from PLD and Tomasz especially can confirm)
and by trying to come with a technical solution for Gnome-1.x . I don't
think I will be able to contain this that much longer, and the Gnome
release team may face this directly, and that's what I tried to avoid.
Maybe a switch which would allow to use the parser from 1.x vs. the
new parser could be added. I could probably hack this, but I would like
before hand the agreement that the Gnome 1.x release team will accept to
release this library. Anyway if there isn't a clear indication from the
release team that a workable solution will be available soon, I'm afraid
I won't be in the capacity to refrain people from upgrading to a new
version of the library.
Contrary to what seems Maciej belief, I'm trying to save Nautilus-1.0
release from immediate obsolescence, not to kill it. If PLD or more
importantly Ximian switches to libxml2, I'm afraid the bonobo they release
would break Nautilus in a far more difficult way to fix than the libxml1
CVS head. I would prefer to come with a cleaner solution, maybe we won't
have any other choice than to ship a libxml1 with 2 parsers switchable
at runtime, this may work.
Daniel
--
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
veillard redhat com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]