Re: [xml] unsinged short for line numbers

On Wed, Feb 14, 2007 at 10:30:58PM +1100, Michael Day wrote:
Hi Daniel,

  This has been explained many times in the past. This is an API and ABI
breakage, I just Can't Do That , at least not for libxml2, and there is
no plan for libxml3.

In a way it is strange that an open source library can be just as 
constrained as a closed source library in this way.

  Oh, it's not, just grab the source and fork it ! Please rename 
if you end up shipping, that's all.

I believe that FreeType changed its API last year, which involved fixing 
many dependent packages. The Linux kernel seems to change its API every 
few minutes, but I guess userspace is largely insulated from the churn 
by sticking to the POSIX parts of glibc.

  I would have to rev the shared lib sonames at least, and then handle
the flow of problems because people used the wrong includes or such.

 Plus from a pragmatic point of view, I don't see people go chase at line
234567 in an XML file with an editor to fix a problem. Either it's not
automatically generated XML and that's positively insane in so many ways
that's it's a minimal problem, or it's repetitive and the error is likely
to show up in others records in the first few megabytes of the XML file,
and that should be sufficient to fix the generator.
  Basically it's a request for something which is not clearly useful, but
if we had gone 32 bits from the start would have used more memory for
keeping a tree without a clear advantage. I prefer to facilitate proper
use of XML than be detrimental to such use in order to ease somehow broken
use of XML. Pick your poison, I choosed when I decided to make this a 
16bits field.


Red Hat Virtualization group
Daniel Veillard      | virtualization library
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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