Re: DOCBOOK-APPS: two issues with XSLT processors -- xsltproc and xalan
On Mon, Mar 17, 2003 at 09:44:11AM -0800, Bob Stayton wrote: > On Mon, Mar 17, 2003 at 11:06:48AM -0500, Daniel Veillard wrote: > > On Mon, Mar 17, 2003 at 09:50:57AM -0500, Robert P. J. Day wrote: > > > to get indented, hierarchical output: > > > > > > 1) works great with xalan. xsltproc, on the other hand, doesn't > > >seem to recognize this attribute although, in all fairness, > > >no XSLT processor is *required* to do so > > > > It does for me, I use it all the time :-) > > It works for me with xsltproc as well (libxml 20504, > libxslt 10027). In the case of fo output, there are many Okay, the whole problem is for HTML output. Basically libxslt/libxml2 does not indent, it just use line returns. The reason is taht HTML output is targetting web browsers, and web browsers acts as a very annoying population when it comes to reacting on white space, seems none of them really follow the rules of HTML whitespace significance, and as a result doing a real indenting is very tricky to get right on the full set of existing browsers. So for HTML output I only do the minimal work allowing to keep the output readable but not taking any risk. HTML and XML serialization code are completely different in libxml2. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: two issues with XSLT processors -- xsltproc and xalan
On Mon, Mar 17, 2003 at 09:50:57AM -0500, Robert P. J. Day wrote: > > to follow up bob stayton's recent posting on adding > to get indented, hierarchical output: > > 1) works great with xalan. xsltproc, on the other hand, doesn't >seem to recognize this attribute although, in all fairness, >no XSLT processor is *required* to do so It does for me, I use it all the time :-) I'm surprized. However libxml2 serialization layer is very cautious about indentation, if there is a text node found in the set of siblings it will cowardly but safely refuse to add extra indentation. The other problem possible might be related to indent inherited value when there is a hierarchy of stylesheets but I never got a clear bug report about this. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: no wonder i'm confused about the node() function
On Sat, Mar 15, 2003 at 03:57:28PM -0500, Norman Walsh wrote: > Since import precedence is the primary discriminator for template > matching, I think the test above should match comment and processing > instruction nodes. > > So I think it's an xsltproc bug that they don't. Which has been fixed in CVS the next day it got reported on GNOME bugzilla... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: Problems with saxon, XML Catalogs,and dbnotnx.mod
On Fri, Mar 14, 2003 at 09:07:34AM +0100, Steinar Bang wrote: > >>>>> Steinar Bang <[EMAIL PROTECTED]>: > > [snip! DocBook XSL stylesheets and XML Catalogs on RedHat 8.0] > > > Presumably this caused the docbook-style-xsl to tidy up after > > itself, when being removed? And my RPM doesn't put anything in > > (yet). > > I took at look at the spec file from the docbook-style-xsl source RPM > for RedHat 8.0, and discovered the xmlcatalog utility: > http://www.xmlsoft.org/xmlcatalog_man.html > > Very useful! Should make it easy to manipulate the system XML > catalogs from RPMs. Thanx for writing it, Daniel. Yep, the pre and post install scripts of Red Hat RPMs for DocBook and XHTML resources, we use it to create/remove the associated resources from the catalog as the package is installed/removed. It can also be used to check programmatically (from a Makefile or configure) if a resource is available in the catalog. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: Problems with saxon, XML Catalogs,and dbnotnx.mod
On Thu, Mar 13, 2003 at 12:52:58PM +0100, Steinar Bang wrote: > In addition there is the file > /etc/xml/catalog > which works for the DTDs, but doesn't have a for the > DocBook XSL style sheets (at least not for my RPM of 1.60.1). Strange, depend on the stylesheet URL you're using, which one ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: srcdir/objdir issues and including variableusability issues with xsltproc
On Sat, Mar 08, 2003 at 12:54:36PM +, John Levon wrote: > On Sat, Mar 08, 2003 at 12:45:46PM +, John Levon wrote: > > > OK I've just tried it again with : > > > > XML_CATALOG_FILES=xsl/catalog.xml:/etc/xml/catalog xsltproc -o \ > > Just to clarify, I tried with the documented space separator as well > -seems my xsltproc is too old to handle two values in this variable. > > I also tried the nextCatalog approach - also fails. All this works for my regression tests. Update and if you still have troubles, post a bug report see http://xmlsoft.org/XSLT/bugs.html for instructions. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xslt mailing list?
On Thu, Feb 27, 2003 at 06:21:38AM -0500, Robert P. J. Day wrote: > > i'm about to sit down with kay's 1000-page XSLT book and > a keg of coffee. is there an XSLT-specific mailing list > somewhere that i can antagonize on occasion? The XSL-List, hight traffic AND high quality usually XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsl-fo: title page customization and bug resolutionin xsltproc
On Wed, Feb 19, 2003 at 12:40:57PM -0800, Bob Stayton wrote: > On Wed, Feb 19, 2003 at 09:46:23AM -0600, Damian Kohlfeld wrote: > > I had the same problem over the weekend. This must be a problem with > > xsltproc, > > I filed a bug against libxslt on Bugzilla for this problem. This should be fixed in libxslt-1.0.27 (with libxml2-2.5.4) which was released yesterday. thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problems validating author-element
On Mon, Feb 24, 2003 at 11:29:18AM +0100, Joachim Ziegler wrote: > What am I doing wrong here: > > >Joachim >Ziegler >[EMAIL PROTECTED] > > > > xmlint says: And the bug report page says: http://xmlsoft.org/bugs.html What about doing those checks first ? There have been bugs fixed in the validation code and there is a couple of outstanding problems. Not even knowing the version used means very little can be done to give you an answer. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsl-fo: title page customization and bug resolutionin xsltproc
On Wed, Feb 19, 2003 at 12:40:57PM -0800, Bob Stayton wrote: > On Wed, Feb 19, 2003 at 09:46:23AM -0600, Damian Kohlfeld wrote: > > I had the same problem over the weekend. This must be a problem with > > xsltproc, > > I filed a bug against libxslt on Bugzilla for this problem. Got it. Strange I though I added those empty namespace declarations *only* for the default namespace when asked to generate a node without namespace while the default namespace is set. I will try to kill it before the next release. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsltproc segfaults after upgrading to xslstylesheets v1.60.1
On Tue, Feb 18, 2003 at 06:53:01PM +0100, Patrick Eisenacher wrote: > Those are the latest versions available with Cygwin. Checking your > reference, I realized they are somewhat outdated. I will ask the Cygwin > people to upgrade the libxml and libxslt packages. Thanks for pointing out. Igor Zlatkovic provides binaries compiled with MSC that should allow to check whether there is still an error with the new version: http://www.zlatkovic.com/projects/libxml/ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsltproc segfaults after upgrading to xslstylesheets v1.60.1
On Tue, Feb 18, 2003 at 04:58:21PM +0100, Patrick Eisenacher wrote: > $ xsltproc -version > Using libxml 20423, libxslt 10013 and libexslt 705 http://xmlsoft.org/XSLT/bugs.html Check the following too before posting: make sure you are using a recent version, and that the problem still shows up in those Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Breaking a document into smaller pieces
On Tue, Feb 18, 2003 at 12:00:13PM +0100, Joachim Ziegler wrote: > Daniel Veillard wrote: > > And that's normal. You must provide the encoding information if > > it can't be guessed as UTF8 or UTF16. Your file is not well formed XML as > > is. > > > > Daniel > > > > ok, I do now: > > xmllint -valid --encode ISO-8859-1 --noout LEDATutorium.xml I don't understand what you're trying to achieve: --encode ISO-8859-1 asks to serialize in that encoding while --noout ask for no output one of them is redundant. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Breaking a document into smaller pieces
On Mon, Feb 17, 2003 at 04:35:59PM +0100, Joachim Ziegler wrote: > If I don't start my chunk-files, say "chapter1.xml", with an > XML-declaration like > > > > > I get the following error from xmllint. > > xmllint -valid --noout LEDATutorium.xml > chapter1.xml:5: error: Input is not proper UTF-8, indicate encoding ! > Auf die Plätze - fertig - los! And that's normal. You must provide the encoding information if it can't be guessed as UTF8 or UTF16. Your file is not well formed XML as is. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Docbook xsl stylesheets and accessibilityrequirements?
On Thu, Feb 13, 2003 at 06:30:29PM +, Dave Pawson wrote: > At 07:58 13/02/2003 -0500, Daniel Veillard wrote: > > And it's not a bug, it's a feature ! > > You sound like Redmond Daniel :-) Well, being able to generate multi-rooted entities can be useful > Personal view. > Its easier to generate good XML using XSLT, than using many other tools. > Like most tools, XSLT can generate cr ap too. For XML I agree. The problem in that case are XHTML1 specific serialization rules. And the only solution I had was to have libxml2 "sniff" the DOCTYPE and use special code implementing those extra rules. And except for namespaces nodes this seems to work fine. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Docbook xsl stylesheets and accessibilityrequirements?
On Wed, Feb 12, 2003 at 09:20:20PM -0600, Adam DiCarlo wrote: > [EMAIL PROTECTED] writes: > > > A general question for folks. If one is stylesheet agnostic, would DSSSL or > > XSL be a better choice for a start toward producing XHTML Strict? I was a > > LISP hacker in a previous life, and so find DSSSL appealing. > > Since the docbook-xsl from the DBOR (Docbook Open Repository) already > has XHTML output and the docbook-dsssl does not, I would imagine it's > easier to work from what is already there. Bit of warning: XSLT1.0 has no provision for the "special" serialization rules of XHTML1 . In xsltproc I do check if the resulting DOCTYPE is XHTML1 and will apply those but I don't think you can rely on this as being portable. Concerning validity and xmlns, XHTML1 (erroneously IMHO) only allow it on the root html element. There is no rule in XSLT saying that an XSLT processor must minimize the namespaces declarations generated or try to coalesce them. Both specs leave a gap and there is no guarantee possible that you will get the prefect match you expect. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Docbook xsl stylesheets and accessibilityrequirements?
On Wed, Feb 12, 2003 at 02:39:39PM -0600, Adam DiCarlo wrote: > > Validity is *very* hard to achieve for arbitary valid DocBook input. > > No XSLT author could ever promise that all output generated by his > > XSLTs will be valid, AFAICS. > > I need to learn more about XSLT -- is this really true, can someone > other than Tobias confirm it? I know it's true of DSSSL but I thought Not only that, but you can't even garantee that the output will be well formed. XSLT can actually generate multirooted entities, so don't even expect anything about validity. http://www.w3.org/TR/xslt#section-XML-Output-Method And it's not a bug, it's a feature ! All XSLT processors who generate XML output have to follow that model. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xalan c++ chunking problems
On Tue, Feb 11, 2003 at 10:37:58AM -0800, Carlos Araya wrote: > Lisa: > > Chunking is done via extensions and, as far as I know, they are only > implemented for Java processors (Saxon, and Xalan for sure, maybe XT is > still supported). No, libxslt/xsltproc have been implementing this and other EXSLT extensions for more than a year. There is a life outside Java ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Docbook xsl stylesheets and accessibilityrequirements?
On Mon, Feb 10, 2003 at 03:42:54PM -0500, ed nixon wrote: > To start the ball rolling, some topics might be: > * how do you get valid html output for which versions of html? BTW Ed, I just released libxml2-2.5.3/libxslt-1.0.26 , it should fix the problem you had with XHTML serialization. Daniel P.S.: there is also some Relax-NG suport but I'm not sure it's good enough to play with the DocBook Relax-NG schemas -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: [Fwd: phantom xmlns in xhtml [was: DOCBOOK-APPS: xhtmlcustomization]]
On Fri, Jan 31, 2003 at 03:05:07PM -0500, ed nixon wrote: > I'll log another bug report with the xmllib/xsltproc folks about this > anomaly. Thanks. This is I think fixed in the latest version. Please check with it *first* ! If it's not precompiled for Windows, then recompile it yourself, please. Don't send me bugs because you didn't tried the last version, thanks. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: XInclude, XSLTProc, and entityref
On Thu, Jan 30, 2003 at 09:57:44AM -0500, Jeff Beal wrote: > I'm trying to use XSLTProc to "flatten" a file using XInclude, then pass > this file through Saxon to create my online help. I first used just the > xmllint parser to parse the file, and noticed that none of the graphic > entities were declared, so I decided to write an XSLT stylesheet to convert > all entityrefs to filerefs. This stylesheet works perfectly on the > XIncluded files themselves, but it fails to resolve the entityrefs on the > same files when they are XIncluded into a larger document. I end up with a > bunch of fileref="" in my resulting XML file. The weird thing is that all > entityrefs resolve normally when using the DocBook stylesheets. > > My template in question is: > > > > > > > Can anybody see what it is that I'm doing wrong? Hum, I smell some kind of bug/problem where the entity definitions from the XIncluded files are not available in the resulting document being transformed. As a result unparsed-entity-uri() which look for those in the document DTD ends up generating an empty strings. Can you bugzilla this with a minimal test case, instructions at http://xmlsoft.org/XSLT/bugs.html thanks, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Saxon crashing: java.lang.StackOverflowError
On Tue, Jan 14, 2003 at 04:42:51PM -0500, Jeff Beal wrote: > hard-coded s into s. (By 'a bunch' I mean 15,000.) XSLTProc > was also crashing after the change. Can anybody think of any reason why Hum ... how ? some guidelines at http://xmlsoft.org/XSLT/bugs.html Capturing the standard error output of the run with -v (cautious this will generate huge logs) and looking at the tail of the logs may help understand the problem. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problem using profiling stylesheets with xsltproc
On Mon, Dec 02, 2002 at 10:20:49AM -0800, Bob Stayton wrote:
> On Sat, Nov 30, 2002 at 08:25:11PM -0600, John Himpel wrote:
> > xsltproc \
> > --catalogs \
> > --nonet \
> > --xinclude \
> > --output ./html/${1}.html \
> > --stringparam profile.condition FullRel \
[...]
> > runtime error: file
> > file:///usr/share/sgml/docbook/xsl-stylesheets/html/profile-docbook.xsl
> > line 219 element apply-templates
[...]
> > c) XSLTPROC has a problem
>
> I think it is a bug in xsltproc.
> The problem is that in the template named
> "head.keywords.content", there is a recursive
> call to the same template.
[...]
> Since this doesn't occur with the same template in
> docbook.xsl, it would appear that the difference is that
> profile-docbook.xsl is operating on a exslt nodeset. But I
> can't explain it any further than that.
Right, it was a bug in the XPath evaluation in that case.
The fix is now in CVS for the libxml2 module, will be in the next
release.
bug report:
http://bugzilla.gnome.org/show_bug.cgi?id=100271
Fix:
http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=gnome-xml&who=veillard&date=explicit&mindate=2003-01-10%2012:05&maxdate=2003-01-10%2012:07&cvsroot=/cvs/gnome
thanks for the report !
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Warnings with xsltproc and DocBook XSL Stylesheets1.59.0
On Sun, Jan 05, 2003 at 11:57:50AM +0100, Sebastian Bergmann wrote: > After upgrading libxml2, libxslt and xsltproc to the current CVS HEAD > I get the following warnings: > > file:///e%3A/home/docbook/xsl/html/callout.xsl:7: warning: xmlns:xverb: > URI com. > nwalsh.xalan.Verbatim is not absolute > version='1.0'> Hum, right, relative URI for namespace name are deprecated, libxml2 was catching the problem for default namespace but not for non-default ones and I fixed this in CVS. Seems either the namespace names should be fixed (might be hard) or the warning should be ignored ... maybe I should add --nowarning of xmllint to xsltproc . Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
DOCBOOK-APPS: Re: DocBook XSL Stylesheets v1.58.1 released
On Tue, Dec 31, 2002 at 04:34:10PM -0500, Norman Walsh wrote: > | I had a look at it, more specifically to docbook.py which contains the > | implementation of the extension functions. I am tempted to simply convert > | that to C as part of libexslt, but there is that big warning in the README > | saying it doesn't work... hum depending on *what* doesn't work it may or may > | not make sense to do that conversion. Any hint on the exact part where > | the problem is ? > > Actually, I think that one does work, but there are three or four much > more substantial functions to be written (and I'm sure there will be > versions of docbook.py that don't work in the process ;-). > > When I've got them all done, I'll let you know and you can think about > turning them into C. Okidoc, deal ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: how to get xsltproc to generate "tidy" html?
On Tue, Nov 12, 2002 at 05:38:15PM -0500, Robert P. J. Day wrote: > > i'm sure numerous folks will tell me that this is a silly > thing to do, but is there a parameter somewhere that will > tell xsltproc to generate tidy html from docbook, so that > it's at least remotely humanly readable, rather than one > long line? Hum, seems that an xsl:output indent option should be sufficient for this. I suspect that Norm doesn't activate this because this may generate rendering troubles though. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: no ID for linkend
On Thu, Dec 26, 2002 at 08:51:52PM +0100, Gabor Hojtsy wrote: > Hi! > > I just tried to build a CHM out of the PHP Documentation sources > using xsltproc, and I keep getting: > > | Error: no ID for constraint linkend: funcref. > | Error: no ID for constraint linkend: langref. > | Error: no ID for constraint linkend: features. > | Error: no ID for constraint linkend: appendixes. > | Error: no ID for constraint linkend: language.basic-syntax.phpmode. > | ... > > While the IDs are there of course. If I add any XML node with > any of these IDs, xsltproc first says I have duplicate IDs, and > then in the next step of the process says, there is no ID for > constraint linkend... First are you using the latest versions of libxml2 and libxslt ? I have fixed such a problem a couple of releases ago. ftp://ftp.rpmfind.net/pub/libxml/ Current is libxml2-2.4.30 and libxslt-1.0.23 Second, the XSLT stylesheets do not use the ID attribute properties anymore to locate the linkend, but a key based on //*[@id] as I discovered while debugging the previous problem. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsltproc crash with some customization
On Tue, Dec 24, 2002 at 10:29:48AM +0100, ABX wrote: > I want to warn about some crashing in xsltproc under NT4: [...] > when I removed that "toc.section.depth" line from my common.xsl either > xsltproc and saxon renders fine without any stop or crash. Provide a full set of sources allowing me to reproduce the crash, I can't make guesswork with cut and paste of fragments and not even knowing the stylesheet used. Guidelines for reporting bugs are at http://xmlsoft.org/XSLT/bugs.html > Happy Christmas, ABX That's the third incomplete bug report that I get in my inbox this morning, this doesn't put me in a festive mood. It's actually very irritating to consider that people don't care following the instructions one provides. Oh well, ... maybe I simply shouldn't read my mail during hollidays. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xmllint and &
On Wed, Dec 18, 2002 at 09:06:49AM +0100, Morus Walter wrote: > Daniel Veillard writes: > > On Tue, Dec 17, 2002 at 10:58:04AM -0500, Jeff Beal wrote: > > however I note that the DTDs installed on my system for DocBook have > > > > instead in docbook/xml-dtd-4.2-1.0-14/ent/iso-num.ent > > but older version had the old style declaration but commented: > > 3.1.7/ent/iso-num.ent: > > > > > > strange, > > > There's nothing strange here. > It's just one of the reasons, why you don't like mixing SGML and XML > applications on unix. > > The reason why you don't see a problem in your test, is that you don't use > the entity. If you add a '&' and use xmllint --loaddtd you will > get the error. So your test case is a bit too small. > > XML *requires* amp to be declared as > > (or & if one prefers hex codes) > See section 4.6 of the xml spec. > > I think the reason is, that reading the entity declaration makes > & from &, which is read again when the entity is used giving > &. If you just declare it as & reading the entity declaration gives > & and when the entity is used a single '&' is found. Hum, right, I remember about this when I was debugging libxml2 entity processing... There was this argument too (James Clark IIRC) that since amp is predefined in the XML specification, that was overriding any declaraction made in the DTD, but weel the best it to fix the DTD, you are right. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xmllint and &
On Tue, Dec 17, 2002 at 10:58:04AM -0500, Jeff Beal wrote: > I'm getting the following error when parsing my documentation with xmllint: [...] > When I edit my local copy of the DocBook DTD and remove the following line > from the iso-num.ent file, everything works: > > > Any comments or suggestions on how to fix this without messing with the DTD? > I have, by the way, verified that xmllint is reading the other character > entities just fine. It seems only to be a problem with the & entity. And I don't understand what's happening, no such problem on a smaller testcase: paphio:~/XML -> cat tst.xml paphio:~/XML -> cat tst.dtd paphio:~/XML -> xmllint --loaddtd --noout tst.xml paphio:~/XML -> and it's the first time I heard of such a problem. however I note that the DTDs installed on my system for DocBook have instead in docbook/xml-dtd-4.2-1.0-14/ent/iso-num.ent but older version had the old style declaration but commented: 3.1.7/ent/iso-num.ent: strange, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sun, Dec 15, 2002 at 06:56:15PM -0600, Adam DiCarlo wrote: > most sysadmins. And I have a hard time really deciding between > whether /usr/share/xml is really a win for sysadmins or not. Well I have good reasons, working both as a tool maintainer and as part of a large OS distributor to think that it has to be separated. Your viewpoint as a user is one thing, do you want to get my support request on the issue ? I would be sooo happy to delegate. I can't do any automated catalog management because a few key individuals, all mostly SGML only users, decided two years ago it wasn't a good idea because they didn't see the need. The attitude "it works for me, let's screw everybody else" tends to piss me off really fast. Last post from me on that thread, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sun, Dec 15, 2002 at 05:09:27PM -0600, Adam DiCarlo wrote: > Sidenote: I really don't see what the big deal is though with mixing > XML and SGML stuff in /usr/share/sgml -- most of the tools I happen to > use work perfectly with both, and I haven't seen any big problems with If you give an SGML entity declaration to an XML parser in most case the syntax is not XML and the parser has to stop with a fatal error. I have seen big problems. If your tool works perfectly with both it probably mean they are SGML tools or not compliants. The formers will have a hard time with xml:base, xinclude, an in general any stuff added to XML which wasn't present in SGML. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sun, Dec 15, 2002 at 11:04:08AM +, Dave Pawson wrote: > At 05:33 15/12/2002 -0500, Daniel Veillard wrote: > >Hum, for xsltproc I added a --nonet option which will make the > >processor barf if it had to go and fetch a non-local resource. > > (is --nonet the default Daniel? Or a selected option). it's not the default, you must add it to the command line > Again remember the context Daniel. >~From the list traffic, I'm getting the feeling that docbook usage > is having a rising take-up rate. Well and looking at IRC the DocBook related Q/A in the GNOME IRC channels have a lot more volume than what you see in #docbook :-) Most of the DocBook users I know are not in dockbook-apps list either... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sun, Dec 15, 2002 at 10:05:46AM +, Dave Pawson wrote: > At 14:33 14/12/2002 -0800, Bob Stayton wrote: > >My doc covers both file path references and catalog references. > >For those just getting started, it is simpler to point to a > >real file on their local system. After they get that working, > >I have a whole chapter on XML catalogs. > Having been there and suffered Bob, perhaps a mention of the symptoms of > the processor going to the web (succeeding or failing), and how/where it Hum, for xsltproc I added a --nonet option which will make the processor barf if it had to go and fetch a non-local resource. For general debugging, still in the same framework, exporting the environment variable XML_DEBUG_CATALOG allow to trace the accesses and failure for resolving resources names against the catalog used. http://xmlsoft.org/catalog.html#validate > I found it infuriating at first, especially when, having done it and got it all > working, Norm produces a new version and I have to do it all again! Yup, unless using the "latest" canonical URI which should be remapped locally to your latest installed version. The problem is that it's a bit error prone (e.g. when Norm removes/renames some existing template rules which are in use by your customization layer :) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sat, Dec 14, 2002 at 02:29:59PM -0800, Bob Stayton wrote: > Thanks for the suggestion, but I couldn't find anything > in the LSB documents about XML stylesheets. > Maybe you are thinking of the "Filesystem Hierarchy > Standard", which is part of LSB. The latest version is > 23 May 2001. It is available at > http://www.pathname.com/fhs/ > > It says to use /usr/share/sgml for SGML and > XML applications. It mentions a docbook subdirectory for > the DTD, but makes no mention of stylesheet locations. > > I don't like using a path with "sgml" in it for a book > that only covers XML. Maybe I'll just use /usr/share/xml. Hum, I generated a number of flamewars in that group by suggesting XML resources should not be mixed with SGML (because this is very error prone). Maybe one day someone will have the time and energy to get this fixed. In the meantime well everybody uses "/usr/share/sgml", hopefully no instance will use it so it won't be dramatic if the location changes at some point. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sat, Dec 14, 2002 at 02:33:53PM -0800, Bob Stayton wrote: > My doc covers both file path references and catalog references. > For those just getting started, it is simpler to point to a > real file on their local system. After they get that working, > I have a whole chapter on XML catalogs. Okay, sorry I didn't went to the source to grab the full context, it my fault, I stand corrected :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"
On Sat, Dec 14, 2002 at 02:59:21PM -0600, Adam DiCarlo wrote: > I find the file paths your citing rather odd and probably not very > exemplary. For instance, in bottom of ch 5, you cite the XSL > stylesheet at the location /usr/lib/xsl/docbook/html/docbook.xsl which > doens't conform to FHS filesystem standards. Ideally the file > locations should comply with the LSB/XML standard, although I can no > longer find that standard (!! maybe it's dead?). Hum, you should not use file path anyway in the instances of the documents or in the tools. if you use the stylesheet PI or even on the command line for xsltproc it's more reliable/portable to use the canonical URL for the stylesheet http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl then if there is a local instance, it should be registered in the XML catalog and the remapping will/should be transparent. This is especially important when such URL are embedded into document instances. It may take a bit of time before every tools and systems set up the catalogs but really that's the best situation, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: DocBook XSL Stylesheets v1.58.1 released
On Tue, Dec 03, 2002 at 07:32:55AM -0500, Norman Walsh wrote: >The 1.58.1 release adds some initial support for extensions in >xsltproc, adds a few features, and fixes bugs. > > o This release contains the first attempt at extension support for >xsltproc. The only extension available to date is the one that adjusts >table column widths. Run extensions/xsltproc/python/xslt.py. Hi Norm, I had a look at it, more specifically to docbook.py which contains the implementation of the extension functions. I am tempted to simply convert that to C as part of libexslt, but there is that big warning in the README saying it doesn't work... hum depending on *what* doesn't work it may or may not make sense to do that conversion. Any hint on the exact part where the problem is ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: troubles after changed encoding in XSL 1.58
On Tue, Dec 03, 2002 at 03:50:52PM -0500, Jeff Beal wrote: > I knew I should have looked at the latest documentation. (Still using 1.48 > stylesheets for HTML) So is the "problem" fixed ? Reading the thread I can't tell if there was a bug to be reported or if it was "just" a configuration problem. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
On Sun, Dec 01, 2002 at 09:07:45PM -0800, Bob Stayton wrote: > On Sun, Dec 01, 2002 at 11:38:07AM +0100, Yann Dirson wrote: > > My opinion is still that we need to be able to validate before, and that > > does not prevent to validate after as well. [...] > > Yes, and IMHO not adding the xinclude elements to the DTD will effectively > > constraint the use case of DocBook. > > It isn't that we (the DocBook Technical Committee) don't > want to add an xinclude element, or that we think it is > not needed. It would be easy to add an xinclude > element to the DTD. But that isn't enough, because > the xinclude element must appear > in content models for it to be useful. [...] > Consider also that xincludes are very much like system > entity references. A system entity reference can replace > just about any content in a document. And everyone seems to > accept the fact that the document cannot be validated until > the system entities are resolved. Validating XML editors > must be able to resolve system entities to be truly > validating. Why not extend that mechanism to resolve > xincludes? It seems that the hard part has already been > done, now they just need to handle some different syntax > for specifying the included text. I would just like to add the point that in most cases where XInclude is used to remplace external parsed entities, while you cannot validate the top document, one can still validate the included documents. I think that's the key point for usability, in the sense that if the document is being worked my multiple authors, each of them can actually validate their piece while they work. And if they use XInclude at their level, they should have no trouble to validate their subtree after XInclude processing. I'm actually quite pleased with the way XInclude is getting used (at least in the community I follow), I was thinking the ability to validate subdocument would be the key reason to use it, but in fact the capability to include text part like code examples coming from external files untouched seems to be the most used feature here, parse="text" is a winner :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: DOCBOOK: Bug?
On Fri, Nov 22, 2002 at 09:51:09AM -0800, Bob Stayton wrote: > On Fri, Nov 22, 2002 at 04:48:36PM +0100, Stefan Priebsch (e-novative GmbH) wrote: > > Hi list, > > > > we've just experienced the following: when creating an empty title > > () for a table and creating XHTML using the 1.57.0 > > stylesheets, the is missing in the list of tables HTML, which screws > > up the following line, of course. > > > > Is there anything wrong on my side or does this happen to be a bug? > > > [moving this to the docbook-apps list] > > What you are seeing is actually a closed XML element: > > 2.1. > ^ > > The trailing slash closes the empty element. > This is perfectly valid XML, but HTML browsers don't > understand it. This is one of the incompatibilities > between XHTML and many current browsers. For those using xsltproc, I just released libxml2-2.4.28 which should close this problem. The XML serializer look at the DOCTYPE and if XHTML1 will then make the appropriates changes listed in the XHTML1 spec, example paphio:~/tmp -> xsltproc docbook-xsl-1.56.1/xhtml/docbook.xsl sample.xml http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";>Trivial exampleTrivial example Just a trivial docbook article. paphio:~/tmp -> things like the meta charset tag, and Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: Announce: DocBook XSL 1.58.0 test release
On Thu, Nov 21, 2002 at 12:45:01PM -0500, Norman Walsh wrote: > | But when I try to run it, it says it can't find the libxml2 library. > | Is that a python library, or the standard libxml2 library? > | (which is installed) > > I don't know. I thought the python bindings for libxml2 were > automatically installed when you installed libxml2. If the import > statement at the top of xslt.py can't find libxml2, I'm clueless. > > Daniel? Oh, Daniel?!... :-) Yeah, bob need to install the libxml2 and libxslt python bindings. should be relatively easy on Linux (I ship RPMs for those libxml2-python and libxslt-python) but you will need recent versions (more precisely last Friday 2.4.27/1.0.23 releases :-) . This seems more bleeding edge on Windows though someone at Zope was actually looking at it recently... The best solution may still be that now that we have a python description of those extensions for libxslt to simply map them back to C and have them registered within libxslt or libexslt :-) Oh and upcoming in the libxml2 front, the XML serializer no detects XHTML1 Doctypes and applies the appropriate rules when selected, which means that the xslt/docbook.xsl stylesheets will soon actually generate correct XHTML1 . Should be available once I release libxml2 2.4.28 (and xsl:output method="xhtml" ain't really needed :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problem with XInclude
On Wed, Nov 20, 2002 at 12:09:18PM +0100, Sebastian Bergmann wrote: > Daniel Veillard wrote: > > Well there is something strange there. > > I don't have the time to dig into this right now, all I can say is that > it works fine in a small text.xml file, but now in my project. > > If i do > > http://www.w3.org/2001/XInclude";> > encoding="iso-8859-1" > parse="text" /> > > > instead of declaring the namespace once in the tag it work, too. Hum, that sounds like a bug then, but I really don't see how such a behaviour could happen. Any chance you can provide a tarball of the input and the command useed to trigger this, I'm puzzled... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problem with XInclude
On Wed, Nov 20, 2002 at 12:31:32PM +0100, Sebastian Bergmann wrote:
> Daniel Veillard wrote:
> > If you want to help me, quickly log a bug on Gnome bugzilla for libxml2
> > about it, taht way whatever happens I won't forget it !
>
> http://bugzilla.gnome.org/show_bug.cgi?id=99082
Excellent, I have no excuse if it's not fixed in the next release :-)
thanks !
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problem with XInclude
On Wed, Nov 20, 2002 at 11:48:53AM +0100, Sebastian Bergmann wrote: > Daniel Veillard wrote: > > * the value of the encoding attribute if one exists > > My bad, I expected the encoding to be inherited from the document to > which fragments are included. Hum, I checked my code quickly, it seems I didn't yet implemented this If you want to help me, quickly log a bug on Gnome bugzilla for libxml2 about it, taht way whatever happens I won't forget it ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problem with XInclude
On Wed, Nov 20, 2002 at 11:35:05AM +0100, Sebastian Bergmann wrote:
> Bob Stayton wrote:
> > Or you could switch to xsltproc with the --xinclude option,
> > which handles xincludes natively as it processes the stylesheet.
>
> This might be the final reason to switch to xsltproc. However, it gives
> me
>
> "Namespace prefix xi is not defined"
>
> warnings, although I have
>
> http://www.w3.org/2001/XInclude";>
Well there is something strange there. It should work, and your report
doesn't allow me to even try to guess where the problem might be... here
are some guidelines:
http://xmlsoft.org/XSLT/bugs.html
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problem with XInclude
On Wed, Nov 20, 2002 at 11:21:40AM +0100, Sebastian Bergmann wrote: > Sebastian Bergmann wrote: > > Thanks, that works. > > Or so I thought at first. > > In the XInclude'd files I have, for instance, german umlauts which now In what encoding ??? > get displayed incorrectly in the output HTML. Time to read the spec : http://www.w3.org/TR/xinclude/#text-included-items -- The encoding of such a resource is determined by: * external encoding information, if available, otherwise * if the media type of the resource is text/xml, application/xml, or matches the conventions text/*+xml or application/*+xml as described in XML Media Types [IETF RFC 3023], the encoding is recognized as specified in XML 1.0, otherwise * the value of the encoding attribute if one exists, otherwise * UTF-8. Byte sequences outside the range allowed by the encoding are a fatal error. Characters that are not permitted in XML documents also are a fatal error. [Definition: A range of characters (the selected range) may be identified by a fragment identifier.] The syntax of the fragment identifier is interpreted using the syntax of the fragment identifier for the media type text/plain. In the absence of a fragment identifier, the selected range contains all the characters in the resource except the initial byte order mark (BOM) if one is present. A BOM is the character U+FEFF when it appears as the first character in resource encoded in UTF-8, UTF-16 or UTF-32. UTF-16BE and UTF-16LE will not contain a BOM. -- How do you get the encoding of a .php file, what's his mime type, if not you will have to make it UTF8 (or UTF16). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: how to get xsltproc to generate "tidy" html?
On Tue, Nov 12, 2002 at 05:38:15PM -0500, Robert P. J. Day wrote: > > i'm sure numerous folks will tell me that this is a silly > thing to do, but is there a parameter somewhere that will > tell xsltproc to generate tidy html from docbook, so that > it's at least remotely humanly readable, rather than one > long line? just curious. having it a bit more readable > makes it easier to debug glitches when one is forced to > look at the page source. thanks. Hum, strange, I would expect the stylesheets to ask for indentation of the output (this can be controlled from within stylesheets with completely standard XSLT ... however the expected behaviour of indenting is not clearly defined, you should at least get line breaks to make the output more readable.) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Output escaping with xsltproc and profilingstylesheet
On Tue, Nov 12, 2002 at 08:55:08AM +0100, Peter Kullmann wrote: > I have the following problem when profiling my docbook sources using > profile.xsl: xsltproc does not escape special characters like ">" in CDATA > sections. [...] > I'm not quite sure whether this is a stylesheet bug or an xsltproc bug (I'm > pretty sure it's a bug, though). I can file a bug in either the xsltproc or Yup, a bug in libxml2, the mechanism which prevented xsltproc from generating CDATA nodes when parsing the input got broken (recently I assume during some refactoring), and the presence of CDATA nodes instead of text nodes in the input tree generated that erroneous output. Will be fixed in the next release of libxml2 (patch enclosed if urgent), Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ Index: parserInternals.c === RCS file: /cvs/gnome/gnome-xml/parserInternals.c,v retrieving revision 1.60 diff -c -r1.60 parserInternals.c *** parserInternals.c 22 Oct 2002 17:35:33 - 1.60 --- parserInternals.c 12 Nov 2002 10:33:50 - *** *** 2250,2256 ctxt->space = &ctxt->spaceTab[0]; ctxt->sax = sax; ! initxmlDefaultSAXHandler(sax, xmlGetWarningsDefaultValue); ctxt->userData = ctxt; ctxt->myDoc = NULL; --- 2250,2256 ctxt->space = &ctxt->spaceTab[0]; ctxt->sax = sax; ! memcpy(sax, &xmlDefaultSAXHandler, sizeof(xmlSAXHandler)); ctxt->userData = ctxt; ctxt->myDoc = NULL;
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 01:58:30PM -0600, Paul Grosso wrote: > > The XML spec in 4.2.2 explicitely state that in production 75 > >the System ID is an URI-Reference and link to RFC 2396. > > RFC 2396 <ftp://ftp.ietf.org/rfc/rfc2396.txt> defines: > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] > > The XML spec says a system identifier cannot include a fragment identifier. > > So the XML system identifier matches [ absoluteURI | relativeURI ] > in RFC 2396 (for which there is no single name given in 2396) > whereas the URIs matched by the uri catalog entry match the full > URI-reference production above. The spec says it's an URI-Reference. It references the RFCs explaining how to compute the final URI from those references. The fact that there are restrictions from the full set admited as the URI-References input doesn't mean that the mechanism should not be used. The only meaning is that one cannot try to point to a subsection of the target resource, period. It does not mean that the URI-Reference to URI mechanism by composition to the base must be voided or be made specific. > > The XInclude spec does the same for the href attribute. > > There is no XML Base, so both references uses the same base > >and anybody with some common sense would expect the two references > >to get to the same resource. > > An XInclude href consists of a URI. An XML doctype declaration's > ExternalID consists of both a public identifier and a system identifier. > They sound very different to me, and it makes perfect sense for two > such different references to be able to resolve to different resources. When there is a public ID, then the public ID may point to something else. In the case where there is twice the exact same system ID I don't see any reasonnable justification to distinguish those. You're asking for the same resource, why would you magically get different results ? Moreover when there are both System ID and Puyblic ID the XML Catalog spec clearly separate the lookup processing by public and system ID. As a result the work to be done on a system ID is exactly similar to the one one need to take for another URI reference except the identifiers in the catalog need to be magically different. > I very much disagree with your "broken" assertion, Daniel. I ask of resource A, then A again, and get different results without the actual resource having changed in the meantime. Yeah I think this is broken, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
DOCBOOK-APPS: Re: XML catalog resolution problems
On Wed, Oct 30, 2002 at 12:31:32PM -0800, Norman Walsh wrote: > I am, to be frank, disappointed and frustrated that you've blown a > great big hole in a smooth operation of XML Catalogs. The whole point > was interoperability and you've $%#$@#ed that up. 1 user complain in 15months of operations. You call that "$%#$@#ed that up" while IIRC I was the first implementor ??? Now I am the one disapointed ! > I think your action threatens the whole enterprise and it's deplorable. What will the spec be completed ? So far I have seen no movement since Aug 01, I raised my point shortly after because I got users reporting to me they got confused by the distinction (because initially I tried to make the separation). At that point I basically received an answer without content. So I merged both notions an had no problem until the beginning of this thread. In retrospect saying the course of my actions is to threatens the XML Catalog deployement could only be looked at with amazement for example from the Gnome community, damn, I got beaten and had to fight there to have them deployed . To be frank, it's my turn to be disappointed and frustrated :-( I take patches usually !!! Usually people who have troubles send me patches or report the problems they face, then I fix them. Show me a final version [*] of the XML Catalog spec and I will either fix the problem or remove the support. Daniel [*] http://www.oasis-open.org/committees/entity/ doesn't show any update since the 06 August 2001. -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote: > > I haven't received any justification yet from the commitee about the > >reason to distinguish those exept "they are different", no sorry ... > > Well, when Microsoft said "I see no reason not to support empty end > tags (i.e., ) in XML", people rose in protest. One justification > is that this is the standard, and you are refusing to follow it. Thanks for the association, greatly appreciated :-((( There was technical reason exposed for refusing once being that redudancy allowed to catch errors. There was support for having clearly marked ending tags outside of the XML Working Group, I have yet to see one user which is not confused by the SYSTEM/URI distinction. I mean real user, the categories of persons I tend to get them to adop XML, and use Catalogs, not a 20 years veteran specialized in the field. > But I will try again to give you a more technical explanation. > > The use of systemId in the XML Catalog is expressly to model > production [75], ExternalID, of the XML spec. I think it is > good architecture to model what the catalog does on what the > XML spec is doing. The XML spec in 4.2.2 explicitely state that in production 75 the System ID is an URI-Reference and link to RFC 2396. The XInclude spec does the same for the href attribute. There is no XML Base, so both references uses the same base and anybody with some common sense would expect the two references to get to the same resource. > XML has no concept of a URI. It only has a concept of ExternalID > with a SystemLiteral. It does expose the System ID as being an URI reference, sorry reread 4.2.2, it does reference RFC 2396 and Co. > Furthermore, XML's SystemLiteral cannot have a fragment ID: Which is precisely a rule it adds at the semantic level on that string associating it as an URI precisely ! > So the datatype of the systemId entry is different from the datatype > of the uri entry. Another reason it makes good architectural No both are a URI References. XML may impose some restriction on the final URI generated. XInclude also expose sonme restrictions, but those are two object of the same kind with the same properties and with the same base they ought to point to the same resource ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote: > Many XML processors provide an option to "compile" the external > subset for certain optimized uses, so the system identifier (in > the doctype line) might really resolve to some compiled form, > but the URI in the xinclude element would want to resolve to > the uncompiled form. haha, that's the underlying implementation breakage which is the cause of all this !!! This means you have internal APIs which doesn't allow you do make the differentiation, this does not justify pushing that differentiation at the description level, sorry :-( > Or I might know that my application ideally supports a slightly > different version of the DTD, so I want to map the system id > into some other file--maybe one on my local system, or maybe > off to the latest test version of the DTD on sourceforge--but > the version I want to include as text in my document should be > the official current version of the DTD. Hum, and you expect this to not lead to huge confusion As a result all users for all XML tool chain using catalogs suddenly MUST duplicate ALL their SYSTEM entries into URI entries just to avoid this ? This is broken ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 09:28:44AM -0600, Paul Grosso wrote: > At 12:27 2002 10 30 +0100, Jeanson Mauritz wrote: > > >When trying xsltproc, I found that it accepts and resolves > >entries for stylesheets in catalog files. As I take it, this is not > >the correct behaviour. > > > You are correct, xsltproc is not in compliance with the XML Catalog spec. > > The XML Catalog spec makes it clear that system entries are for > resolving external identifiers (production 75 in XML) and clearly > says about URI entries [1]: And I have said to the XML Catalog comitee that an URI Reference is an URI-Reference and that having to distinguish arbitrarilly one done from a DOCTYPE entry from one done from an xi:include href entry doesn't make any sense to me, and that I would not support the distinction in my software unless getting a meaningful reason to distinguish those. I haven't received any justification yet from the commitee about the reason to distinguish those exept "they are different", no sorry ... I see ZERO reason why the two following URI-Reference made from a single XML entity should lead to using different resource for http://example.com/foo.dtd: --- http://example.com/foo.dtd> http://example.com/foo.dtd"; parse="text"/> --- This distinction is extremely confusing, and so far can't be justified I really don't see why it's there and the intended purpose. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: attribute sets
On Thu, Oct 10, 2002 at 04:52:59PM -0700, Bob Stayton wrote: > On Thu, Oct 10, 2002 at 06:04:03PM -0400, Daniel Veillard wrote: > > On Wed, Oct 09, 2002 at 04:48:06PM -0500, Dennis Grace wrote: > > > > > > Okay, I guess I don't get it. How do I make use of the attribute-sets in a > > > customization layer? I tried this: > > > > > > > > >10pt > > >bold > > >false > > > > > ="keep-with-next.within-column">always > > > > > > > > > And it did nothing. If I make the font-size change directly to the > > > param.xsl file, that works. All my param settings work, but the > > > attribute-sets don't. Am I missing an important step? > > > > > > DocBook XSL 1.55.0 > > > xsltproc (libxml2 2-4-24/libxslt 1.0.20) > > > > hum okay, that's the latests. The bug should be fixed in libxslt-1.0.22 which was just released (as well as libxml2-2.4.26) see ftp://xmlsoft.org/ ori ftp://ftp.rpmfind.net/pub/libxml . Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Weirdness with SGML_CATALOG_FILES for xsltproc underWindows
On Tue, Oct 15, 2002 at 09:31:55AM -0400, Philip Glaser wrote: > Running xsltproc under Windows, I've already discovered the > peculiarity of the syntax you have to use in order for xsltproc to > successfully locate a catalog file (file:///d:/path/to/file.soc). > Now I've discovered that xsltproc will only recognize the catalog > file, in this format, if it is the _last_ in the list of > directories specified in SGML_CATALOG_FILES. If it helps, here is > the entire contents of SGML_CATALOG_FILES: > > c:\sp\pubtext\xml.soc;D:\Data\DTDs\docbook\docbook.soc;D:\Data\DTDs > \xhtml1\xhtml.soc;d:\data\dtds\featureset\featureset.soc;d:\data\dt > ds\xslt1.1 > xslt.soc;file:///d:/data/dtds/xslt1.1/xslt.soc;file:///d:/data/dtds > /featureset/featureset.soc;file:///D:/Data/DTDs/docbook/docbook.soc > > This is a real pain as it means anytime I want to use a different > dtd I have to edit the variable. Any suggestions would be most welcome. The way to report xsltproc bugs is described at: http://xmlsoft.org/XSLT/bug.html Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: conditionalization of XML
On Fri, Oct 11, 2002 at 06:09:37AM -0400, Eric S. Raymond wrote: > So I've written a tool that throws away that whole level of structure and > gets the job done. I'd sure like to develop a better solution, but you > seem to be intent on denying there is a problem. I don't affirm or deny anything w.r.t. conditionalization needs. I'm just stating my position as the guys who implement and maintain the friggin' code, okay ! I'm not convinced that one need acces to the DocType to conditionalize *processing* . And I'm definitely convinced that it's useless to try to add support for an unstructured processing within an XML toolkit. I don't want to add an add-hoc unspecified unstructured processing to my toolkit and maintain it. Show me a more coherent request and I will re-evaluate it. Mind you I have work to get done too ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: conditionalization of XML
On Fri, Oct 11, 2002 at 06:36:21AM -0400, Eric S. Raymond wrote: > Daniel Veillard <[EMAIL PROTECTED]>: > > I'm not convinced that one need acces to the DocType to conditionalize > > *processing* . And I'm definitely convinced that it's useless to try to > > add support for an unstructured processing within an XML toolkit. > > The problem with not being able to see the doctype is that that means > you cannot pass it through transparently. XSLT cannot reproduce on its > output what it can't see on its input. That's why I gave up on XSLT -- > because *any* stylesheet-based approach to conditionalization will have > the same problem. You want to do XML process X > xmlsubset transform > web or print process X standalone can't be done easilly with XSLT, yes. XML process X + transform > web or print can be done with XSLT assuming the way you tags things integrate okay with the markup, which is *not* the case with PIs > xmlif my be inelegant from a pure XML point of view, but it is > certainly not useless. I'm using it quite effectively every time I > render my document -- in fact it gives me important capabilities I > would not otherwise have. Perhaps you should reconsider your > definition of "useless"? "useless to try to add support for an unstructured processing within an XML toolkit" yes I stand on this, not the proper place. You must understand that at that level I have an in-memory tree and that your are just PIs scattered around the tree and if they are not properly instanciated w.r.t the structure the whole processing fall over. And a solution based on markup tags/attributes and not PIs is likely to be quite simpler to describe fully. > > I don't want to add an add-hoc unspecified unstructured processing > > to my toolkit and maintain it. Show me a more coherent request and > > I will re-evaluate it. Mind you I have work to get done too ! > > I don't know what you would consider a coherent request. Do you want > a more formal specification of the behavior of the PIs? Yes with respect to structure, error handling etc ... And get traction, checking that others are interested in it and have reviewed it. This thread between you and me could go on for ages, it's not the point I don't want to implement something which might be architecturally broken or too limited to be widely useful. You may have 100 MBytes of markup tagged this way, but this won't be the reason why this should be added at the toolkit level. You claim to have the magic solution, I want to hear more voices before commiting on it, especially since I'm not personally convinced it's the right technical approach. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: conditionalization of XML
On Fri, Oct 11, 2002 at 05:38:02AM -0400, Eric S. Raymond wrote: > xmlif knows nothing about the XML structure of the document. All it `sees' > is the processing instructions what is otherwise, from its point of view, > a featureless byte stream. Then there is no good reason to implement it in an XML toolkit, really. Using sed sounds the right tool for the job. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: conditionalization of XML
On Fri, Oct 11, 2002 at 04:41:41AM -0400, Eric S. Raymond wrote: > Daniel Veillard <[EMAIL PROTECTED]>: > > Now to be relatively specific about as much as I can since I > > don't have any clear picture of how the selection is actually done, it seems > > to be in the line of the previously found standard extention abuses > > like #pragma foobar for Winblows C compilers or various custom PI > > that each SGML toolchains seems to have developped to tie in their > > customers in the 90's (I may get some heat for this, I don't care ;-) > > You know, there's reason people keep re-inventing mechanisms for this. > It's because they need to get work done -- and getting work done often > means wanting to conditionalize documents without spending days on some > elaborate custom XSLT hack. But then you put the burden on someone else. And an underspecified, underreviewed mechanism is the hell of the maintainer's > > they really need, that there is a clean and public description with > > review of the suggested extension, then I would certainly be an early > > implementor of said feature. > >Attribute/value pairs from the command line are matched >against the attributes associated with certain processing >instructions in the document. The instructions are and >its inverse , and its inverse , >, and . > >Argument/value pairs given on the command line are checked >against the value of corresponding attributes in the >conditional processing instructions. An `attribute match' >happens if an attribute occurs in both the command-line >arguments and the tag, and the values match. An `attribute >mismatch' happens if an attribute occurs in both the >command-line arguments and the tag, but the values do not >match. > >Spans betweenorand the next conditional >processing instruction at the same nesting level are passed >through unaltered if there is at least one attribute match and >no attribute mismatch; spans between and not?> and the next conditional processing instruction are >passed otherwise. Spans betweenand the next >conditional-processing tag are passed through only if no >previous span at the same level has been passed through. > and(and their `not' variants) change the >current nesting level; and do not. > >All these processing instructions will be removed from the >output produced. Aside from the conditionalization, all other >input is passed through untouched; in particular, entity >references are not resolved. > >Value matching is by string equality, except that "|" in an >attribute value is interpreted as an alternation character. >Thus, saying foo='red|blue' on the command line enables >conditions red and blue. Saying color='black|white' in a tag >matches command-lineconditionscolor='black'and >color='white'. > >Here is an example: > Always issue this text. > > Issue this text if 'condition=html' is given on the command line. > > Issue this text if 'condition=pdf' or 'condition=ps' > is given on the command line. > > Otherwise issue this text. > > Always issue this text. Doesn't cover a hell of issues, 2mn read just pops up tons of unspecified behaviour or serious problems. Heck, even the "condition=" syntax is only given in the example - well formedness breakage, your description is done at the serialization level, it has 0 garantee on the level of XML well-formedness What gives ??? A further XML well formedness error ? In that case it's better left external. Otherwise you'd have to start to give a description in terms of the infoset, or similar like XInclude does. - malformed preprocessor commands unlatched or , etc, etc ... what is handled, and how ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: conditionalization of XML
On Fri, Oct 11, 2002 at 08:52:01AM +0100, Tim Waugh wrote: > On Thu, Oct 10, 2002 at 05:43:38PM -0400, Daniel Veillard wrote: > > > > (1) You add support for ?if? and friends to xsltproc. Probably the > > > fastest route to a complete solution. > > > > > > (2) You tell me you'll take a patch from me to implement them. I'd > > > have to learn the xsltproc code, so it would take longer, but I > > > can do that. > > > > Honnestly 1/ and 2/ are not acceptable. Now if someone decides > > to standardize something like then it's a big mess. > > Moreover if this can be done by a small and fast external preprocessing, > > why try to put everything in the same tool ? > > Eric has written a tool, xmlif, to do this, and it's available in > xmlto-0.0.11pre6. What's a 'big mess', incidentally? Do 'if' et al > need to be namespaced, you mean? Well something like this, basically I believe in standardization, don't blame me on this but I would dislike if people were starting to rely on xsltproc specific behaviour, if that behaviour isn't properly documented and has a sufficiently large user base. Been there, even when conceptually something looks like a very simple tool, it's only when you go through the steps of a large review that you discover the potentially fatal flaws that can be associated with it. As a programmer I prefer to write and maintain code associated to processing which went at least through the first steps equivalent to a standardization track, coding is slow, maintainance is a pain, life is short, enough reasons to be relatively careful about what I decide to implement and maintain. Now to be relatively specific about as much as I can since I don't have any clear picture of how the selection is actually done, it seems to be in the line of the previously found standard extention abuses like #pragma foobar for Winblows C compilers or various custom PI that each SGML toolchains seems to have developped to tie in their customers in the 90's (I may get some heat for this, I don't care ;-) I would really prefer to get DocBook fixed to allow proper conditionalization at the *markup* level (if the current solution is not sufficient for users' needs like Eric), which then will be close to trivial to handle correctly in the existing XSLT tools, independantly of the toolchain used. In a nutshell, my guts feeling is that PIs + custom preprocessing are the kind of patchy' mechanism which would be acceptable if the environment was a locked proprietary toolchain but don't feel right in a DocBook framework where most of the processing is done otherwise with standard tools. Now if a number of people did voice in saying that's the kind of processing they really need, that there is a clean and public description with review of the suggested extension, then I would certainly be an early implementor of said feature. Makes sense ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
DOCBOOK-APPS: Re: conditionalization of XML
On Thu, Oct 10, 2002 at 06:14:59PM -0400, Eric S. Raymond wrote: > What would you consider a complete solution to this problem? I'm not > wedded to xmlif itself, I just need to get some work done that > requires being able to conditionalize stuff. If you think there's a > better way to handle this, I'm open to it. XSLT. Your basic problem is to format to print and web version. I don't see the core reason why this can't be possible with XSLT. You have troubles but they are mostly related to the fact that you want to operate as a preprocessor instead of symply relying on stylesheet customization, and/or markup extensions, but I may be missing the point. Of course if you're using PIs to do this markup, it's by essence unstructured and hence make it difficult to handle easilly at the XSLT level. Well simply use markup extension to do this. > > Can't you just sed the output in case of errors ? > > s/^processed/orgiginal/ > > of the stderr stream doesn't sound hard to setup ... > > Fine if I'm processing errors in batch mode, yes. But I mentioned Emacs > for a reason... I don't use Emacs, but I don't see why you couldn't make it execute a wrapper shell around the XSLt processor instead of running the processor directly. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: attribute sets
On Wed, Oct 09, 2002 at 04:48:06PM -0500, Dennis Grace wrote: > > Okay, I guess I don't get it. How do I make use of the attribute-sets in a > customization layer? I tried this: > > >10pt >bold >false > ="keep-with-next.within-column">always > > > And it did nothing. If I make the font-size change directly to the > param.xsl file, that works. All my param settings work, but the > attribute-sets don't. Am I missing an important step? > > DocBook XSL 1.55.0 > xsltproc (libxml2 2-4-24/libxslt 1.0.20) hum okay, that's the latests. I though xsl:attribute-set was okay in xsltproc (there is a good test case in the libxslt regression tests tests/general/bug-80.xsl ). I don't understand why this would not work, maybe because it extends a set present in an imported stylesheet or something like that. What happen if you move this block from your customization layer to param.xsl ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: attribute sets
On Thu, Oct 10, 2002 at 02:58:04PM -0400, Norman Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > / Dennis Grace <[EMAIL PROTECTED]> was heard to say: > [...] > | process. Nothing I put in an attribute-set in my customization layer does > | anything (my list.block.spacing doesn't work, either). > | > | Could this be an xsltproc problem? > > Sounds that way to me. > > Can you try another processor? First make sure you use a recent version, second I would really appreciate a small isolated (i.e. not depending on the huge DocBook stylesheets) test case exhibiting the problem if it happen to be a bug. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
DOCBOOK-APPS: Re: conditionalization of XML
On Thu, Oct 10, 2002 at 02:42:48PM -0400, Eric S. Raymond wrote: > Daniel Veillard <[EMAIL PROTECTED]>: > > This will be in the next libxslt release. > > Can you give us a rough timeframe? When it's ready. > And what do you expect the release number > to be? Probably 1.0.22 usually within one month. http://xmlsoft.org/XSLT/news.html > While we're talking command-line options, Daniel, I have a small request. > It's for a small hook in xsltproc that would address a general problem. [...] > But there's a problem. An old familiar one, generic to the use of all > kinds of preprocessors. When I'm browsing XML errors in my Emacs > window, they point to the processed file rather than the original > input. Aaarrgghh! [...] > There are a couple of different ways we could go to solve the problem: > > (1) You add support for ?if? and friends to xsltproc. Probably the > fastest route to a complete solution. > > (2) You tell me you'll take a patch from me to implement them. I'd > have to learn the xsltproc code, so it would take longer, but I > can do that. Honnestly 1/ and 2/ are not acceptable. Now if someone decides to standardize something like then it's a big mess. Moreover if this can be done by a small and fast external preprocessing, why try to put everything in the same tool ? > (3) You add --error-filename. Has the advantage that it could be used > with other preprocessors. Basically the problem is that the processor working on a processed file gives back the error in terms of the processed file filename and line number instead of the original one. I can hardly see how it could be otehrwise, the line number will be wrong anyway and even attempting to provide the initial filename is only a partial solution due to the entities support problem. Who else is gonna use this switch ? I could try to hack this but this sounds partial solution and not of widespread use, right ? Technically it would be messy too, the error reporting routine is within the library and uses the document URL as the resource name source, changing it would require a global variable in the library, and that I try to avoid adding as much as possible. Can't you just sed the output in case of errors ? s/^processed/orgiginal/ of the stderr stream doesn't sound hard to setup ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Manually Chunking with PIs
On Thu, Oct 10, 2002 at 05:05:58PM +0100, Tim Waugh wrote: > On Thu, Oct 10, 2002 at 11:45:26AM -0400, Daniel Veillard wrote: > > > There is also a couple of new options: > > --nowrite : refuse to write to any file or resource > > --nomkdir : refuse to create directories > > > > To be able to protect the environment when the stylesheets are not considered > > trusted enough. > > It would be useful if you could limit creation of files to within a > particular directory, but I realise that's non-trivial. Well, simply make a preference callback checking the value, plug it in and you're done. Should be actually relatively simple to add to xsltproc now :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Manually Chunking with PIs
On Tue, Sep 03, 2002 at 06:02:35AM -0400, Daniel Veillard wrote: > On Tue, Sep 03, 2002 at 11:56:16AM +0200, Janning Vygen wrote: > > Am Montag, 2. September 2002 16:42 schrieb Jirka Kosek: > > > Janning Vygen wrote: > > > > 3. Directories cant be created by the XSLT Processor. Does > > > > anybody has written a stylesheet converting toc file to a shell > > > > script which creates all needed directories? > > > > > > This depends on OS and processor used. E.g. Saxon on Windows is > > > able to create directory if it doesn't exists yet. > > > > Yes, you are right. I forgot to say that i am using linux and > > xsltproc. Saxon uses java api to extend the possibilities and it > > works on linux as well as on windows. [...] > > Wouldn't it be better to have an XSL Stylesheet which generates a > > file with the needed directories? > > Honnestly, no ! That could turn into a nasty security problem. > When an XSLT engine is embedded in say a web server, it's already a > bit hazardeous to allow creating files (extending libxslt to have > some policy control over potential security hazards is an interesting > TODO item), I wouldn't allow to create directories ATM, there is too > many security implications (think about a sytlesheet with an hidden > template creating .ssh/authorized_keys for example). > Too dangerous without a proper framework, I started implementing the framework. The patch I commited at http://cvs.gnome.org/bonsai/cvsquery.cgi?module=libxslt&branch=HEAD&branchtype=match&dir=libxslt&file=&filetype=match&who=veillard&whotype=match&sortby=Date&hours=&date=explicit&mindate=10%2F10%2F02+11%3A25&maxdate=10%2F10%2F02+11%3A27&cvsroot=%2Fcvs%2Fgnome provide the necessary hooks for access checking and defining a policy of access. As a result xsltproc should create new directories when needed. There is also a couple of new options: --nowrite : refuse to write to any file or resource --nomkdir : refuse to create directories To be able to protect the environment when the stylesheets are not considered trusted enough. This will be in the next libxslt release. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: problems with publishing cvs refguide
On Wed, Oct 09, 2002 at 04:13:55PM +0200, Patrice DUMAS - DOCT wrote: > I have a redhat 7.3. > > [dumas@hermes defguide]$ xsltproc --version > Using libxml 20419, libxslt 10015 and libexslt 706 > xsltproc was compiled against libxml 20418, libxslt 10015 and libexslt 706 Independantly of the bug reported, you should really upgrade to the latest versions of libxslt and libxml2 for DocBook processing. The rpms are on ftp://xmlsoft.org/ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: [DOCBOOK] docbook buttons?
On Tue, Oct 08, 2002 at 08:42:55AM -0400, Norman Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > / "Daniel S. Haischt" <[EMAIL PROTECTED]> was heard to say: > | is there a docbook button available? > > If you accept my crude renditions as "available" > > http://docbook.sf.net/release/buttons/website-1.png > http://docbook.sf.net/release/buttons/docbook-1.png > http://docbook.sf.net/release/buttons/slides-1.png I like those :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: [DOCBOOK] docbook buttons?
On Tue, Oct 08, 2002 at 02:29:42PM +0200, Daniel S. Haischt wrote: > the button should be similar to the button > that you have to add to your site if your site > is hosted at sourceforge (88 x 31 pixels). > > is there a docbook button available? if there is no official Logo, I suggest someone with knowledge of Photoshop/Gimp/whatever makes one based on the duck of the DocBook Book, assuming O'Reilly is fine if the project reuses the image for DocBook related icons. A good logo do make a difference, and IMHO the duck rocks ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
On Fri, Oct 04, 2002 at 12:28:29PM +0200, Yann Dirson wrote: > On Fri, Oct 04, 2002 at 05:52:05AM -0400, Daniel Veillard wrote: > > The more I think about it, the more I'm convinced that > > in general, validation should occur after XInclude processing. > > IIRC that would not meet the definition of "validity" for an XML > document, or am I wrong ? If you can find a definition for an XML document, then maybe ;-) I think it fits the definition for the stream of bytes coming out of the XInclude process. The XML processing model is probably not something we should explore too much in the DocBook list, there are other hot channels for this, but I think it would be reasonable to document the expected processing steps (possibly multiple path like FO vs. PassiveTex), if we didn't already. > > But allowing an extra attribute everywhere is quite simpler > > than allowing an extra element everywhere :-) > > "everywhere" is probably too strong, i bet noone wants to use this for > inline elements. Well, it's hard to predict a priori in what way people are gonna use a relatively new tool, I would not constraint the use case while there have been only little use so far. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
On Thu, Oct 03, 2002 at 10:27:23AM -0700, Bob Stayton wrote: > One little item... > I've noticed in your example and the XInclude Candidate > Recommendation that the content model for xi:include is: > > > > Shouldn't there be a question mark to make xi:fallback optional? > > > > The spec [1] seems to permit this. Here is the relevant part: > > 4.4 Fallback Behavior > XInclude processors must perform fallback behavior in the > event of a resource error, as follows: > > If the [children] of the xi:include element information item > in the source infoset contain exactly one xi:fallback > element, the top-level included items consists of the > information items corresponding to the result of performing > XInclude processing on the [children] of the xi:fallback > element. It is a fatal error if there is zero or more than > one xi:fallback element. > > When I first read this, the final sentence suggested that > xi:fallback is required. But that sentence is qualified > by the first paragraph, which says fallback is invoked > only when a resource error occurs (when the xinclude URI can't be > resolved). [...] > [1] XML Inclusions (XInclude) Version 1.0 > W3C Candidate Recommendation 17 September 2002 > http://www.w3.org/TR/xinclude/#fallback Dohh, okay that's a bug in the XInclude spec IMHO The (non-normative) DTD example in 3.1 should really read to match the prose and the present in the Schemas on top of section 3. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
On Thu, Oct 03, 2002 at 02:28:27PM +0200, Karl Eichwalder wrote: > Peter Ring <[EMAIL PROTECTED]> writes: > > > First I'd like to lobby for keeping your local copies of DTDs and > > stylesheets as a mirror or cache of the canonical URLs. > > There is no such thing like a canonical URL. Use a catalog and map > PUBLIC identifiers to local resources. There is even for docBook stylesheets. I asked Norm in this list before generalizing XML Catalog support in Gnome the answer was yes, http://docbook.sourceforge.net/release/xsl/current http://docbook.sourceforge.net/release/xsl/$version You should really start accepting that URL can be used as identifiers like any other string, sigh ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
On Wed, Oct 02, 2002 at 09:49:09PM -0700, Bob Stayton wrote: > I started to extend the DocBook DTD to permit xi:include, > but I think it is kind of impossible (except for maybe > Norm 8^). The xi:include element can replace *any* > element or group of elements, so the content models of > every element would get hopelessly complex. The more I think about it, the more I'm convinced that in general, validation should occur after XInclude processing. The only painful point are the xml:base attributes left on the included elements when the resources included are not in the same directory as the including resource. But allowing an extra attribute everywhere is quite simpler than allowing an extra element everywhere :-) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: modular docbook documents using xpointer
On Thu, Sep 26, 2002 at 11:08:06AM +0200, Arno Sosna wrote: > > Because they select the top-level-included-items and what gets > > produced in the result tree are all the subtrees under tose selected > > nodes. No change in semantic at the XPointer level, just a > > misunderstanding > > of the XInclude specification. Please read it :-) > >http://www.w3.org/TR/xinclude/#dt-top-level-included-items > > so basically it means, that the error is in the syntax, not the tool, am i > right? Well in this case this doesn't seems a bug in the implementation :-) > which leads me back to the problem of not knowing how to do it :-) > well, i guess back to xpath/xpointer... It may actually be difficult to do "filtering out" operations with XInclude + XPointer. Seems such an operation is more easily done further in the processing chain for example by skipping the elements at the XSLT level. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: modular docbook documents using xpointer
On Thu, Sep 26, 2002 at 10:29:13AM +0200, Jirka Kosek wrote: > Bob Stayton wrote: > > > > Use #xpointer(//*[not(ancestor-or-self::chapterinfo)]) > > > > > > What is nice on XPath is that you never know it enough ;-) > > > > Did this XPath actually work for you? > > I was writing it from top of my head, I though it will work as XPointer > is superset of XPath. My xsltproc doesn't signal error, but for every > node selected by this expression returns also its subtree resulting in > messy output. It means that either XPointer semantic in context of > XInclude is defferent than I though or that there is error in xsltproc. > Maybe DV can put some light in this area. Because they select the top-level-included-items and what gets produced in the result tree are all the subtrees under tose selected nodes. No change in semantic at the XPointer level, just a misunderstanding of the XInclude specification. Please read it :-) http://www.w3.org/TR/xinclude/#dt-top-level-included-items Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xmlns attribute in xhtml output...
On Wed, Sep 18, 2002 at 12:52:19PM -0400, ed nixon wrote: > Sorry for this one, I suspect it's a real chestnut. > > Processing my sdbook file with xsltproc and the xhtml/docbook.xsl from > version 1.55.0 on Win2K, I'm getting xmlns attributes in every html > output tag. > > Neither my XMetal validator nor my Homesite validator like this very > much, not at all, in fact. > > I assumed the xhtml would be valid out of the box, so to speak; is there > a parameter or command switch that needs to be set to get rid of the > namespace attribution? What version of xsltproc ? Try to upgrade to the latests (2.4.24/1.0.20) versions of libxml2/libxslt . Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problems with XSL stylesheets 1.55.0
On Wed, Sep 18, 2002 at 01:55:36AM -0700, Bob Stayton wrote: > On Wed, Sep 18, 2002 at 11:24:39AM +0200, Giuseppe Greco wrote: > > I replaced the XSL stylesheets 1.54.1 with the > > the XSL stylesheets 1.55.0. > > > > Well, with version 1.55.0 I'm able to generate > > FO output, but I'm not able to generate HTML > > output. xsltproc simply does nothing and never > > returns the control... > > Chunking, right? > The problem might be that > in 1.55.0, Norm changed the statements > in html/chunk.xsl to use remote http URLs instead of relative > file paths. You might be having problems retrieving > the remote files. He changed the paths back in CVS, so you > could pick those up or change chunk.xsl to use local > file references. Or install a catalog ! http://xmlsoft.org/catalog.html http://xmlsoft.org/XSLT/docbook.html Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: Announce: DocBook XSL Stylesheets V1.55.0released
On Tue, Sep 17, 2002 at 10:39:28AM -0400, Norman Walsh wrote: > | Why are files included/imported from the web? > > Because any other URI depends on my local organization and history has > demonstrated that mine is not the one true way. Everytime I include a > URI of the form "../../stuff" or worse "file:///stuff", it fails for > someone (and almost everyone, respectively). > > So I've switched to using globally accessible URIs. I strongly suggest > that you use an entity resolver to redirect such attempts to your > local filesystem. Or edit the files on your host to use local URIs. One more step to push for XML Catalogs (or catalogs in general), thumbs up ! BTW Norm, any news on finalizing XML Catalog (i.e. getting rid of the System/Uri split , adding cache level semantic and publishing it as a finalized spec ;-) ? Feel free to redistribute my request to the People Who Can ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Problems with tables using XSL FO stylesheets.
On Fri, Jun 14, 2002 at 01:04:34AM -0500, Eric Baudais wrote: > I've been trying to get the tool chain DocBook -> xsltproc -> passivetex > -> pdf to work. I've run into two problems doing this. The first > problem involves xsltproc. I tried to run xsltproc with Norman Walsh's > fo stylesheets using the command: > xsltproc -o book.fo > /usr/share/xml/docbook/docbook-xsl-1.51.1/fo/docbook.xsl book.xml > I get the error: > Error Undefined namespace prefix > xmlXPathCompiledEval: evaluation failed > Segmentation Fault > > So, I tried using an older version of the fo stylesheets and 1.48 or > 1.50.0 seemed to work well with xsltproc. this is being tracked down, not easy, but in progress ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: org.apache.fop.apps.Fop does not generate any output
On Thu, Jun 13, 2002 at 11:32:44PM +0200, Johannes Zellner wrote: > On Thu, Jun 13, 2002 at 02:05:19PM -0700, Bob Stayton wrote: > > On Thu, Jun 13, 2002 at 09:53:44AM +0200, Johannes Zellner wrote: > > > > > > Hi, > > > > > > # org.apache.fop.apps.Fop index.fo -pdf index.pdf > > > [INFO]: FOP 0.20.3 > > > > > > just does not generate any pdf output. > > > But I don't get any error messages. > > > What could be the problem? > > > > Are you able to process other docbook .fo files? > > > > If so, then take a peek inside this one to see if it looks > > anything like the others that do work. Perhaps it > > has no fo:page-sequence elements? > > > > What tools are you using to generate the index.fo file? > > xsltproc > > I tracked down the problem on a different machine. It seems that > 'kaffe' is not able to handle apache's fop. On a different machine > I get with 'kaffe': > > [INFO]: FOP 0.20.3 > java.lang.NullPointerException > at org.apache.fop.apps.Service.providers(Driver.java:586) > at org.apache.fop.apps.Driver.setupDefaultMappings(Driver.java:307) > at org.apache.fop.apps.Driver.(Driver.java:201) > at org.apache.fop.apps.CommandLineStarter.run(CommandLineStarter.java:58) > at org.apache.fop.apps.Fop.main(Fop.java:19) > > with blackdown java everything works fine. Unfortunately there's only kaffe > on the machine at work and I've no root access ;-( hum, there was some discussion on the Kaffe list about running XSLT processors with Kaffe but I can't remember FOP being mentionned. Maybe asking the sysadmin to upgrade to Kaffe 1.0.7 Release Candidate 1 may help, there had been a lot of work recently. http://kaffe.org/cgi-bin/mailman/listinfo/kaffe > Are there any other fop converters except the one by apache? Commercial and closed source ones, yes. In source, I don't think so. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsltproc segfaults with 1.51.1
On Mon, Jun 10, 2002 at 06:18:54PM +0300, Togan Muftuoglu wrote: > * Daniel Veillard; <[EMAIL PROTECTED]> on 06 Jun, 2002 wrote: > >On Thu, Jun 06, 2002 at 11:07:31AM +0200, Camille Bégnis wrote: > >> - a bug in the compilation/packaging step? > > > > I didn't do any regression test with gcc-3.1, just the normal ones > >for the RPM build, if there is on-going problems that might be something > >to check. > > I have one also crashed running on SuSE and it is AFAIK gcc 2.95.3 > > Using libxml 20422, libxslt 10018 and libexslt 709 > xsltproc was compiled against libxml 20422, libxslt 10018 and libexslt 709 > libxslt 10018 was compiled against libxml 20422 > libexslt 709 was compiled against libxml 20422 > > > With xsl-stylessheets version 1.50 there is no problem Damn, the problem is that if I can't reproduce it, it makes the debugging really hard. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsltproc segfaults with 1.51.1
On Thu, Jun 06, 2002 at 11:07:31AM +0200, Camille Bégnis wrote: > So now, what's the problem(s): > - a bug in libxslt ? possibly, one that got fixed in the latest release (it took me one month to make that release, so there is a number of bug fixes in it !). > - a bug in the 1.51.1 XSL? should not make the library crash in any way > - a bug in the compilation/packaging step? I didn't do any regression test with gcc-3.1, just the normal ones for the RPM build, if there is on-going problems that might be something to check. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: xsltproc segfaults with 1.51.1
On Wed, Jun 05, 2002 at 06:09:39AM -0500, Michael Smith wrote: > Camille Bégnis <[EMAIL PROTECTED]> writes: > > > Hmm, tracking down to the code causing the error was easier than I > > thought: the following sample works fine with 1.48 and makes xsltproc > > 1.0.18 segfault with 1.51.1 html (works with FO). > > Yep -- I just tried the same doc instance below on my environment with > xsltproc and the current (cvs) version of the stylesheets > (html/docbook.xsl) and reproduced the same segfault. Hum, I can't reproduce it here: paphio:~/XSLT/tests/docbook -> /usr/bin/xsltproc ~/tmp/docbook-xsl-1.51.1/html/docbook.xsl tst.xml Error Undefined namespace prefix xmlXPathCompiledEval: evaluation failed xsltproc segfault testxsltproc segfault test paphio:~/XSLT/tests/docbook -> /usr/bin/xsltproc --version Using libxml 20422, libxslt 10018 and libexslt 709 xsltproc was compiled against libxml 20419, libxslt 10018 and libexslt 709 libxslt 10018 was compiled against libxml 20419 libexslt 709 was compiled against libxml 20419 paphio:~/XSLT/tests/docbook -> Same for my development version from libxslt/libxml2 CVS, I will dig up about the Undefined namespace prefix error ... but can you check first with the RPMs from ftp://xmlsoft.org/ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Chunked HTML and TOCs
On Tue, Jun 04, 2002 at 11:14:11AM +0200, Michael Wiedmann wrote: > Using: > - DocBook XML 4.1.2 > - DocBook XSL 1.51.1 > - xsltproc (libxml2 2.4.22, libxslt 1.0.18) > > In generating chunked HTML output I want to have TOCs up to the second > level and set the following in my XSL customization layer: > > > > But I get only a complete TOC for the first section and no TOC at the > deeper levels. > > Any hints? As usual trying with another XSLT processor sounds the very first thing to do. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
DOCBOOK-APPS: FYI libxslt/xsltproc release
Just to inform you that the latest libxslt-1.0.18 release should fix the problem of duplicated namespace declarations which were present when using the XHMLT or FO XSLT stylesheets. ftp://xmlsoft.org/ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: wrong sort order of index in HTML
On Sat, May 25, 2002 at 11:43:45PM +0200, Michael Wiedmann wrote: > *But* some of this alphabetical sorted blocks are not sorted in the correct > order, like > > S > T > U > V > A > B > Q > R > > Any hints? trying another XSLT processor to see if it's xsltproc fault's (I hope not, but this is always possible ...) Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Onechunk problem
On Wed, May 15, 2002 at 01:59:11AM -0700, Bob Stayton wrote: > On Wed, May 15, 2002 at 04:15:20AM -0400, Daniel Veillard wrote: > > > It appears that at least one thing that will cause this problem is > > > having spaces in a refname. The current db2man code takes the refname > > > > yes libxslt doesn't cope well with the document extension if there > > are unescaped spaces in the target chunk name (in the URI sense because > > I assume the name is an URI Reference, and then pass it to libxml2 layer > > doing the URI- Ref computation job, which itself fails because "a b" is > > not an URI-Reference). > > I don't know what's the best way to handle this, maybe libxslt could > > URI escape the returned string automatically ... > > If you escape a string containing spaces, what does the filename > look like? the URI-Reference passed to libxml2 would then be "a%20b" I'm afraid you may end up with the %20 in the actual filename generated, I'm not sure the unescaping is always done by the filesystem access layer, of course this can be fixed ... > I experienced this xsltproc error with db2man but my refname didn't > seem to have spaces. But the XML file looked like this: > > mycommandname > ... > > The carriage return whitespace after the name triggered the > error. Hum, in that case I would really blame the stylesheet layer if this doesn't get normalized in some way before using the string as a document name. > I think db2man should be fixing this bug, however. > It should strip leading and trailing whitespace, and > translate spaces to underscores in the name. > I seriously doubt anyone using db2man wants filenames > with spaces or carriage returns, escaped or not. yup, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Onechunk problem
On Wed, May 15, 2002 at 03:03:34AM -0500, Michael Smith wrote: > Bob Stayton writes: > > > On Fri, May 03, 2002 at 03:30:17PM -0500, Dennis Grace wrote: > > > > About my error message: > > > > > > > > Error chapter is not a chunk! > > > > Writing for chapter > > > > runtime error: file > > > > /usr/share/sgml/docbook/docbook-xsl-1.50.0/html/chunker.xsl > > > > line 79 element document > > > > xsltDocumentElem: URL computation failed for > > [...] > > > > The line number reported is the line with the closing ">" > > for exsl:document element. I think the xsltproc parser > > is using that as the element line. I have several files > > that do not generate the error, and two that do, so it is > > not happening with all files. I haven't had time to > > investigate what is different about those two files. > > It appears that at least one thing that will cause this problem is > having spaces in a refname. The current db2man code takes the refname yes libxslt doesn't cope well with the document extension if there are unescaped spaces in the target chunk name (in the URI sense because I assume the name is an URI Reference, and then pass it to libxml2 layer doing the URI- Ref computation job, which itself fails because "a b" is not an URI-Reference). I don't know what's the best way to handle this, maybe libxslt could URI escape the returned string automatically ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: The Best Linux Distribution to work with DocBook
On Mon, Apr 29, 2002 at 09:02:43AM -0300, Jorge Godoy wrote: > SEBASTIÁN VIÚDEZ ORTEGA <[EMAIL PROTECTED]> writes: > > > Between the main Linux distributions - RedHat, > > Suse, Mandrake, etc.-, i would need to know, based in > > your experience, wich one is the more appropriate to > > work with Openjade, Jadetex, LaTex, StyleSheets, > > DocBook-DTD's, Graphics, XML Editors, XML Browsers > > and other related tools, in order to make pdf's, > > HTML's, etc. documents from XML DocBook documents (I want > > to say wich distribution is more complet and updated, and > > less buggy). > > I don't think anyone can answer this without some tendency on the > answer. You should also check which distribution has an active person > on these packages, how often they are updated, how many DTDs are > available, etc. Well I will expose my bias. I am the main author of libxml2 and libxslt (xsltproc), I am paid by Red Hat, and as such I will give priority to Red Hat customers when I'm under time pressure. Tim Waugh also helps a lot on making sure our distribution will work for most documentation needs. That said I think it's well known I tend to process bugs from whoever raises them, even from Windows users. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: XML catalog question and comment
On Tue, Apr 23, 2002 at 02:48:27PM -0700, Eric Richardson wrote: > > Then I point the XSL processor to the catalog location. > > The catalog can resolve pathnames relative to > > the catalog file location. > > The command in the Makefile looks like this: > > > > XML_CATALOG_FILES=/usr/share/xml/catalog/catalog.xml \ > > xsltproc /tools/xsl/docbook/html/chunk.xsl input.xml > > > xsltproc has it's own implementation? well it reuses the one from libxml2 . The xmlcatalog tool comes with libxml2 too. > > BTW, if you are using xsltproc, you'll want > > to initially set the env variable XML_DEBUG_CATALOG=1 so you can > > see how each reference is being resolved. Very helpful > > for debugging unresolved references. > > > You obviously have a great system here. I never thought of using the > resolver to resolve URIs passed to the processor. yes that's very convenient, for example you can generalize the use of the stylesheet PI, make it point to the canonical URI for the XSLT and the catalog will be looked up automatically. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: scaling images in PDF but not in HTML?
On Tue, Apr 23, 2002 at 06:21:08PM +0200, Jirka Kosek wrote: > Steinar Bang wrote: > > > So the question is: do I massage the ? Or do I try to make > > saxon use the proxy server? > > The best solution is to use catalog files within your XML/SGML system. > One way how to add them to Saxon is described in > http://www.kosek.cz/xml/saxon/. Other way is to use XML resolver classes > from Norm, I didn't URL in my hand, try Google or search archives. I have put some explanations on-line too and a specific page for xsltproc users. This is becoming a real FAQ as we are deploying catalogs on Linux/Unix to handle the DocBook docs of the Gnome project http://xmlsoft.org/catalog.html http://xmlsoft.org/XSLT/docbook.html Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Docbook/XML, done with Java
On Wed, Apr 10, 2002 at 03:10:31PM -0500, Matt Reynolds wrote: > On Wed, 2002-04-10 at 14:14, Carlos wrote: > > Matt: > > > > I've used ant with XSLTproc, Xalan and (latest and greatest) with Saxon. The > > build.xml file is listed below. Apologies to the list, wasn't sure if I > > should send this to the list or privately. > > > > Carlos > > > > What is XSLTproc? That's vaguely familiar... > > Sending private (or even better, a link to a web page) works just as > well. But this is OK with me :) Hehe don't worry I will make a bit of advertizing: http://xmlsoft.org/XSLT/ Check the DocBook specific page if you want to set-up catalogs, there are precompiled binaries for Linux, solaris and Windows. And if you manage to have it consume 500MB of memory it means you're probably processing a dozen set of books simultaneously (last time I checked the DocBook Duck Book required 60+MBytes of memory when converted to HTML). Oh, sorry it's not Java but raw, sharpen, C code ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: problems with jclarks "Driver" and docbook-xsl-1.50.0
On Thu, Mar 28, 2002 at 03:16:04PM +0100, Michael H.E. Roth wrote: > On Thursday, 28. March 2002 03:40, Dave Pawson wrote: > At 13:19 27/03/2002 +0100, Michael H.E. Roth wrote: > > > > I'm curious how you came to be using XT rather than a more up to date > > processor? What web (or other reference) took you to XT > > rather than say, Saxon or Xalan? > > > > Regards DaveP > > Well, I downloaded the html-version from docbook.org and there they call xp > the most popular sgml-parser in chapter 3 and in chapter 4 the examples are > with XT and FOP. (the others are just mentioned) > I also tried xsltproc but I couldn't get it to take any parameters - just by > coincidence I came across an article last night where it was mentioned that I > have to enclose the parameter value in double qoutes (but I haven't tried > yet). or use --stringparam "name" "string value" I added it exactly for this. The options are detailed if you just launch xsltproc without any argument. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: MSXML support in DocBook stylesheets
On Thu, Mar 21, 2002 at 03:06:05PM +0100, Jirka Kosek wrote: > I personally appreciate your xsltproc, but on my DocBook documents it is > ~ 50% slower than MSXML4. I'm not using latest version of xsltproc with > new XPath optimizations, my current version is > > Using libxml 20413, libxslt 10010 and libexslt 10010 A challenge is a challenge, I would be interested in reports related to the (libxml 20419, libxslt 10015) combo just released. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: MSXML support in DocBook stylesheets
On Thu, Mar 21, 2002 at 03:49:58PM -0700, Eric Richardson wrote: > Daniel Veillard wrote: > >> OTOH to be honest, I'm mostly using Saxon because I need DocBook > >> XSL specific extensions. > >> > > > > Damn, maybe I should give them a higher priority. > > Is there an overview or something that tells how to write extensions for > the xsltproc engine? can it be written in python or only C/C++? There is some documentation: http://xmlsoft.org/XSLT/extensions.html It may help to read the description of libxslt internals if you want to access contextual informations from the XSLT engine http://xmlsoft.org/XSLT/internals.html The Python extensions doc is at http://xmlsoft.org/XSLT/python.html Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: MSXML support in DocBook stylesheets
On Thu, Mar 21, 2002 at 03:06:05PM +0100, Jirka Kosek wrote: > Daniel Veillard wrote: > > > > MSXML is probably fastest XSLT implementation around (not completely > > > true System.Xml.Transform in .Net is even faster) and I would like to > > > > Can I challenge this claim ? I'm in a mood for a fight. > > Of course you can, but for safety and to prevent flame-wars I used word > "probably". ;-) Yup, seen it :-) > I personally appreciate your xsltproc, but on my DocBook documents it is > ~ 50% slower than MSXML4. I'm not using latest version of xsltproc with > new XPath optimizations, my current version is > > Using libxml 20413, libxslt 10010 and libexslt 10010 [...] > If new version of xsltproc beats MSXML, then there are my > congratulations. Well, I can't tell, I don't have a version of Windows, and don't intend to buy one. It also seems Igor haven't updated the binaries to the latest version, but I would expect them soon apparently he's working on it: http://www.fh-frankfurt.de/~igor/projects/libxml/ > OTOH to be honest, I'm mostly using Saxon because I need DocBook XSL > specific extensions. Damn, maybe I should give them a higher priority. > Having them for xsltproc will be big benefit for me > and others because we can switch to xsltproc and also use its other > interesting features -- e.g. XInclude support. Amen ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: MSXML support in DocBook stylesheets
On Thu, Mar 21, 2002 at 02:43:23PM +0100, Jirka Kosek wrote: > Hi, > > MSXML is probably fastest XSLT implementation around (not completely > true System.Xml.Transform in .Net is even faster) and I would like to Can I challenge this claim ? I'm in a mood for a fight. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
DOCBOOK-APPS: libxslt/xsltproc update
Just an update for people using libxslt/xsltproc, an improvement in the libxml2 XPath engine seems to provide significant improvement when using Norm's stylesheets, there have been a new pair of releases libxml2-2.4.18/libxslt-1.0.14 incorporating those (HTML formatting on some DocBook GNOME doc become nearly 3 times faster). ftp://xmlsoft.org/ On the other hand I still didn't took the time to look seriously at Norm's specific extension functions :-\ Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: Re: xsltproc and tablecolumns.extension (was Re: Noframes around tables - how to activate Saxon extensions for Norman Walsh's XSL1.48?)
On Thu, Feb 28, 2002 at 11:48:54PM +0100, Norman Walsh wrote: > / Alex Lancaster <[EMAIL PROTECTED]> was heard to say: > | that extension. Any word (Daniel V.?) on whether that is planned or > | even possible at some stage in xsltproc? It's not part of the exsl > > Daniel and I have talked about getting the extensions ported over. > He's got some support for extensions in Python so as soon as a couple > of things are worked out, I'll probably try to write them in Python. > Then maybe he can port them to the C code for maximum portability. > (Yes, I could port them to C too, but I bet DV can do it about 10 > times faster :-) Problem is that those extension functions need to return nodesets and I didn't yet finished that part in the Python bindings. I will try to get this in the next release. But since the final goal is to have them directly part of the C implementation getting the Java existing code for the couple of implementations you did already could allow to avoid a round-trip. Where are they ? What are the most critical extensions ? Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
