[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 11:30:28PM +0200, Jean-Baptiste Quenot wrote: > * Daniel Veillard: > > > 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. > > What do you mean? In the source doc, in the stylesheet, or in > xsl:output? If I omit it in xsl:output, I get UTF-8 output, not > entities references. Of course, adding HTML entities references on XML output (the default) would be severely broken. If you use 'just' <xsl:output method="html"/> libxml will try to map all output chars outside ASCII to their entities references. This mode actually gave people who where building publishing solutions a serious headache. The latest libxml2/libxslt 2.4.5/1.0.4 set will use charrefs if using <xsl:output method="html" encoding="ISO-8859-1"/> In general the problem of remapping back the output as entities when all entities context has been lost in the processing seems really too complex. It's doable if you distinguish character entities from larger ones and if you have an a priori knowledge to the serialized DTD, but this doesn't fit well with XSLT processing. Probably better left to another stage in the pipeline. > > There are problems remapping entities, some browsers have well know > > deficiencies to handle some entities (laquo, raquo, oelig, etc ...). > > OK, you're right. But entities references are nicer IMHO ;-) Well I have to compose with different users viewpoints and needs. That part is a bit confusing, the best would be to have a tunable parameter in xsl:output but that would be HTML specific. > OK, it is fixed with 1.0.3. I must give libxslt / libxml a new chance. Okay good to know that a bug was fixed. I try to fix bug really fast, if I get report people usually get a patch or a fix within the next days or couple of weeks unless it really requires infrastructure changes. > > > 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. > > He insists on the future orientation of XSLT to let the users feel how > the standard will evolve, and to avoid that XSLT implementors make the > wrong choices, e.g. concerning the data types involved in processing a > stylesheet. It is fine for a testing environment, very very annoying when you try to build a conformant tool and you users tell you that their stylesheets don't work on your environment because for example Saxon transparently remove the Result Value Tree and Node Set distinction. The one conformant suddenly is the bad guy, quite frustrating on the long term. > > Concerning my own ability at implementing a correct XSLT processor, > > well you may not trust me, others do. > > You may admit that libxslt / libxml has just reached stability. Before > (a few monthes ago), it was not so, xsltproc crashed a lot (sorry for > not having reported the bugs BTW). Indeed you did a _very_ nice job. Well, I wasn't the only one. And hopefully lot of people reported problems allowing to build a good regression testsuite. There is still bugs I didn't fixed yet, but it should be good enough for most "standard" processing. > And xsltproc is FAST!!! (I saw faster processing however using tools > like XSLT -> Java converters: once compiled, it is much faster than > anything else, even xsltproc ;) xsltproc was actually not designed with speed in mind. It reuses the libxml2 DOM building code, and only few key point were optimized. There is still a lot of margin left for future interpreters. > > 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 :-) > > Right. It is left to the appreciation of the implementors ;) > > Keep up the good work, Daniel! Okay, thanks. Clearly one of my goals was to produce tools to allow DocBook processing especially in the Linux/Unix environment, this was and still is my main target. If people use it and find bugs please report them (I still owe Norm at least one bug fix !). 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