Re: DOCBOOK-APPS: Any suggestions on Java problems? (with Saxon)

[Daniel Veillard <veillard at redhat dot com>]

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/

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>