Description of problem: I have been having a fair bit of success building DocBook 5 books from the openstack-manuals project locally in HTML and PDF formats. When I went a step further and tried to use the package command however I encountered this error: WARNING: You can not create RPM packages with a blank abstract. Skipping RPM creation. The book in question does in fact have an abstract but it appears the issue is that the XSL selection only looks at the DocBook 4 style <*info> elements whereas DocBook 5 uses <info>. This is the relevant line from blib/datadir/xsl/abstract.xsl in the publican source tree: <xsl:template match="/"><xsl:value-of select="/bookinfo/abstract"/><xsl:value-of select="/setinfo/abstract"/><xsl:value-of select="/articleinfo/abstract"/> I think the least invasive solution is to look for /book/info/abstract, /article/info/abstract etc. as well (or the equivalent that actually works, my XSL abilities are pretty shoddy). The longer term would be to have different XSL streams entirely for different DTDs (I guess). Version-Release number of selected component (if applicable): publican-3.1.5-0.fc18.noarch
Interestingly I noticed that the equivalent change *has* already been applied in the subtitle.xsl: <xsl:template match="/"><xsl:value-of select="/bookinfo/subtitle"/><xsl:value-of select="/setinfo/subtitle"/><xsl:value-of select="/articleinfo/subtitle"/><xsl:value-of select="/d:info/d:subtitle"/> I applied a similar change to abstract.xsl but it doesn't seem to be working for me at this point, still experimenting.
Ok I worked out what is happening here. As advised above abstract.xsl does need a patch similar to subtitle.xsl that is currently missing, but that doesn't actually solve my use case. The reason is that publican expects that the "info" content to be in its own file. For the OpenStack books I am working with all of the content is in the one "main" file so I have been using these directives to tell publican where everything is: info_file: bk-cli-guide.xml mainfile: bk-cli-guide rev_file: bk-cli-guide.xml This is enough for local builds to work but it causes problems when it comes to these subtitle and abstract XSLs used in publican package. The reason is that they expect the bookinfo/setinfo/articleinfo/info to be the root node of the "info_file". As this isn't the case for me this doesn't actually pick anything up: <xsl:value-of select="/d:info/d:subtitle"/> This does but obviously wouldn't work for more "standard" books: <xsl:value-of select="/d:book/d:info/d:subtitle"/> I'm not sure what the best approach to cater for this would be. Some ideas though: 1) Use a choice so that if the "default" (/d:info/subtitle) doesn't find anything we try (/d:book/d:info/d:subtitle as well). 2) Look for the first subtitle/abstract in the file regardless of parent (dangerous because it might mean that there is in fact none present for the book element but we happily continue after picking up one on a later element).
Created attachment 737633 [details] Patch to datadir/xsl/abstract.xsl The attached patch only fixes the "basic" case by ensuring abstract.xsl also checks /d:info/d:abstract. It does not fix the more complex case whereby the abstract for the book/set/article is nested deeper within the XML tree.
(In reply to comment #3) > Created attachment 737633 [details] > Patch to datadir/xsl/abstract.xsl > > The attached patch only fixes the "basic" case by ensuring abstract.xsl also > checks /d:info/d:abstract. It does not fix the more complex case whereby the > abstract for the book/set/article is nested deeper within the XML tree. Ok, I can see from Bug # 915687 that someone has actually already submitted something similar. The slightly more complex case I am dealing with here is an issue in both DocBook 5 and DocBook 4 books though - that where the info element is nested within the book/set/article container rather than the root node of the document. Alternative patch to follow.
Created attachment 737648 [details] Detect abstract and subtitle even when nested. Updated patch adds detection of abstract in DocBook 5 content *and* ensures that the abstract/subtitle are picked up even in cases where their parent element is not necessarily the root node. In the DocBook 4 case this is done by looking for //bookinfo/abstract (for example) in the DocBook 5 case more specific checks like /book/info/abstract are required.
(In reply to comment #5) > In the DocBook 4 case this is done by looking for //bookinfo/abstract (for > example) in the DocBook 5 case more specific checks like /book/info/abstract > are required. In subsequent testing I've been unable to reproduce the issue described in comment # 4 and comment #5 with a DocBook 4 book, so changes are only required to support DocBook 5.
I had been working around this issue locally but building and installing a new build brought it back to the fore. I don't have an easy way to work around this one (other than messing with the XSL locally once installed). It doesn't appear the XSL in question can be overridden in the brand and the only way to make the source XML match the filter would be to use the old <bookinfo><abstract>... syntax which isn't valid in DB5 at all so results in other failures. This is one of the last barriers between us and (re)publishing DocBook 5 content from docs.openstack.org using Publican (the other one appears to be Bug # 987650 which admittedly I only raised today). Understand that it's now clear that continuing to bastardize the same XSL path is bad mojo for full DocBook 5 support but I'd appreciated an exception in this instance given how close we are to having a minimal set working.
Replaced nasty XSL with beautiful Perl.
HSS-QE has reviewed and declined this request. QE for this bug will be handled by IED.
Verified that publican build and publican package both work in a DocBook 5 book with mainfile, info_file, and rev_file specified, with publican-3.9.9-0.fc19.t7.noarch