[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: Any suggestions on Java problems? (with Saxon)
On Mon, Sep 17, 2001 at 09:51:20PM +0200, Jean-Baptiste Quenot wrote: > I find saxon much better than xsltproc in terms of output. For example, > saxon outputs entity references for latin-1 characters. Also, xsltproc xsltproc will too if you don't specify an encoding. There are problems remapping entities, some browsers have well know deficiencies to handle some entities (laquo, raquo, oelig, etc ...). I could play the game of guessing what entities should be provided and which one should not, etc. by trying on all available browsers. There is unfortunately only one way to make sure character not encodable on the specified encoding will be understood by a given browser, it's to make a decimal character reference. We can then debate what is nicer, a lot of people still have as a priority taht the output is interoperable. > does not yet fully implements the XSLT standard. I once tried to > process a document written with Resume DTD, and xsltproc failed whereas > saxon did the job perfectly. I didn't get any bug report from you. No bug report mean no improvement. Libxml is supposed to implement XSLT-1.0 standard fully. It does not implement XSLT-1.1 which is not a standard (and will never be, it's official). It you tested a few months ago, then no surprize, xsltproc development started in January and 1.0 was only available in July. > If you read M. Kay's book, I'm sure you will be a Saxon addict. IMHO, > it is really a professional XSLT processor, it is very careful about all > the subtleties of implementing XSLT. I am very happy of Mr Kay book. I don't like the way he's playing with the (now dead) XSLT-1.1 spec to not make Saxon compliant to XSLT-1.0. Concerning my own ability at implementing a correct XSLT processor, well you may not trust me, others do. I will also note that conformance to the XSLT specification does *not* include any serialization part (reread the spec if you don't believe me), so bashing libxslt non-conformance on the output would be simply improper :-) Now I still wait for pointer to XSL/DTD where xsltproc fails so I can fix it if this is not the case. 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] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC