Bug 953675
| Summary: | XSL for abstract and subtitle detection assumes *info element is root node of XML file (not always the case when using info_file) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Community] Publican | Reporter: | Stephen Gordon <sgordon> | ||||||
| Component: | publican | Assignee: | Jeff Fearn 🐞 <jfearn> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 3.1 | CC: | aigao, rlandman, xma | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 4.0.0 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-12-19 02:46:49 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 913281 | ||||||||
| Attachments: |
|
||||||||
|
Description
Stephen Gordon
2013-04-18 21:04:21 UTC
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 |