OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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)

* 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.

> 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 ;-)

>   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.

OK, it is fixed with 1.0.3.  I must give libxslt / libxml a new chance.

> > 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

>   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.
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 ;)

> 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!
Jean-Baptiste Quenot

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC