I'm using DocBook 5,
which uses xml:id. Unfortunately, Xerces cannot handle xml:id, which means it
doesn't support XPointers on its own.
I'll do as you suggest
and try to debug the catalog. I'm not having any problems with the catalog using
Saxon-Xerces.
Regards,
Jeff
Jeff,
Are you using Docbook 4 or 5? Also, are you using a current version of the
XSL stylesheets? Is there a reference that tells you that Saxon doesn't resolve
XPointers?
Here is what I know from my own tools. Saxon/Xerxes and XSLTproc handle
XPointers. I use them in every doc I generate. I use XSLTPROC for my production,
but maintain my Saxon tools as well because they will sometimes gives me more
info on a problem than xsltproc. I do use profiling and have not seen anything
like what you are describing lately.
When I was first setting up my tools, I had a dickens of a time using
catalogs. Sometimes they would thrash for a while and error out. So I turned on
catalog debugging and painstakingly went through each line the debugging
produced and massaged it until I was sure of what it was doing. You may be
seeing some of the same issues with your own catalog. If so, turn on the
debugging and weed out the "circulars"
Now, if you are using Docbook 5, then I should bow out of this discussion
since I have not made that leap yet.
Regards
Dean Nelson
In a message dated 3/12/2012 12:08:20 A.M. Pacific Daylight Time,
jpowanda@vocera.com writes:
The problem I'm having
is unrelated to olinks, although I'm not sure what it
is.
All I know is that I
have problems generating larger (~400 pages) books with xsltproc using a
profiling stylesheet. If I generate a small book (50 pages), it generates
without any problems, even if the book has XIncludes with XPointers,
profiling, and olinks.
If I generate a large
book, the catalog resolver chugs along endlessly to resolve generic
addresses to local paths. Not sure why. Perhaps there's infinite recursion
going on. xsltproc eventually runs out of memory. Curious to see if anyone
else observed infinite recursion problems with xsltproc. This doesn't happen
with Saxon-Xerces (but Xerces has other problems with XPointers).
<!-- Fixes a problem with xsltproc and
profiling --> <xsl:param name="inherit.keywords">0</xsl:param>
Curious to hear how you got Saxon-Xerces to work with
XPointers, since Xerces doesn't support xml:id. Do you preprocess the book
with xmllint or another tool?
Regards,
Jeff
I'm curious too about the olink problem you mentioned. Olink
collection and olink resolution should both take place after any XIncludes
have been processed and resolved, so I'm not clear how an XInclude with an
XPointer would create a problem. Can you provide any more specifics
about that problem?
----- Original Message -----
Sent: Saturday, March 10, 2012 3:23
PM
Subject: Re: [docbook-apps] Re:
VirtualBox DocBook 5.0 VM
Jeff,
Maybe I am not understanding the depth of the issue because I use
XIncludes and XPointers and they work for me both in xsltproc and
Saxon/Xerces (I maintain both in my development environment).
I have also used profiling in the past and had no problem. However,
maybe you have come across an issue that I have not seen yet.
Regards,
Dean Nelson
I'm using
single-pass profiling. I've tried using two-pass profiling, and that
allows me to generate our larger books with xsltproc, but when I do that
the olinks to any XIncludes that use XPointers don't get resolved
correctly. XPointers remain a problem for me whether I use xsltproc or
Saxon-Xerces-J (which doesn't support xml:id syntax). Not sure what I
should do, other than avoid using XPointers.
Regards,
Jeff
Jeff,
I use XIncludes, and not olinks or profiling (on the file I just
used). The only difference in the switches is that I use --novalid which
skips the skips the Dtd loading phase.
Are you using single pass profiling or two-pass?
Dean
In a message dated 3/9/2012 10:57:20 P.M. Pacific Standard Time,
jpowanda@vocera.com writes:
Hmm, my docs are tiny
compared to that. Are you using XIncludes, olinks, and
profiling?
Here's how I'm calling xsltproc in my build.bat
file:
call xsltproc.exe --nonet
--xinclude --stringparam profile.condition
%conditions% --stringparam olink.debug 0
--stringparam collect.xref.targets "no"
--output %output_file% --stringparam
insert.xref.page.number yes --stringparam
insert.olink.page.number maybe --stringparam
target.database.document %olink_file%
--stringparam current.docid %doc_id% %xsl_file%
%book_file%
Regards, Jeff
________________________________
From:
DeanNelson@aol.com [mailto:DeanNelson@aol.com] Sent: 2012-03-09
03:06 To: DeanNelson@aol.com; Jeff Powanda;
tom.browder@gmail.com Cc:
docbook-apps@lists.oasis-open.org Subject: Re: [docbook-apps] Re:
VirtualBox DocBook 5.0 VM
One more bit of info. I just ran a
1200 page doc (XP/2Gb/xsltproc) and it used about 230 MB of memory to
churn through that doc.
In a message dated 3/9/2012 2:44:36 P.M.
Pacific Standard Time, DeanNelson@aol.com writes:
Jeff, I routinely process books over 400
pages (XP/2Gb/xsltproc) and rarely see a memory error. However, when I
DO see one, it is because I have done something wacky in the XSL or have
done something in the XML that was "legal" but not supported in the XSL.
Rare though. What command line
switches are you using?
Regards, Dean Nelson
In a message dated 3/9/2012 2:22:48 P.M. Pacific Standard Time,
jpowanda@vocera.com writes:
I'm using the Windows version of
xsltproc.
xsltproc worked fine on our smaller manuals (~50 pages), but it wasn't
able to handle our largest books (~400 pages). I need to be able to
build all the manuals on the writers' machines, which are Windows 7 or
Windows XP laptops with only 2 GB of RAM. Xsltproc couldn't seem to
handle those constraints. Saxon+Xerces can.
If other people are using
xsltproc under similar constraints on Windows and it's working fine,
perhaps I'm doing something wrong.
Regards,
Jeff
-----Original Message----- From: Tom
Browder [mailto:tom.browder@gmail.com]
Sent: 2012-03-09 09:31 To: Jeff
Powanda Cc: Docbook Apps Help
list Subject: Re: [docbook-apps] Re:
VirtualBox DocBook 5.0 VM
On Fri, Mar 9, 2012 at 11:25, Jeff Powanda
<jpowanda@vocera.com> wrote: >
Ok, thanks. I switched from xsltproc a few years ago when it was
> unable to process our largest
manuals (it ran out of memory).
Was that a Windows version, or
*unix?
Size of manual?
I'm sure libxslt folks would love to hear about that whichever
system it was on.
-Tom
---------------------------------------------------------------------
To unsubscribe, e-mail:
docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
docbook-apps-help@lists.oasis-open.org
=
|