Menu
▾
▴
#1088 consistent generate id
When generate.id.attributes is set elements get random ids every build. This creates mess in file history in version control systems. Possible workaround by David N. Welton at http://journal.dedasys.com/2009/09/07/stopping-docbook-version-control-churn
Related
Discussion
You may have good reasons for storing generated files in a VCS, but it is not really DocBook-XSL's fault that the IDs are changing. If you want to use xsl:number instead of generate-id, then it is very easy to customize the "object.id" template in common.xsl, as suggested in the blog post that you referred to. But this is not guaranteed to always work; the number produced by xsl:number can change if the document structure changes.
It is only logical when generated content changes if document structure changes. The opposite is not. As for keeping generated content in VCS - would a reason of automatically updating web site from VCS repository be good enough for this change?
Will the template below produce better default ids?
<xsl:template name="object.id">
<xsl:param name="object" select="."/>
<xsl:choose>
<xsl:when test="$object/@id">
<xsl:value-of select="$object/@id"/>
</xsl:when>
<xsl:when test="$object/@xml:id">
<xsl:value-of select="$object/@xml:id"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="local-name($object)"/><xsl:number level="multiple"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
OK, point taken. Let us think about this some more.
Your original description was basically just a reference to a blog post. It would have been helpful if you had provided more details about your own requirements, and why you (apparently) reject the suggestions mentioned in the comments to that blog post.
Do you mean to assign all elements an id? There was no time to reverse engineer HTML and templates to figure out which elements in sources cause ids to be regenerated on every run, so I just used the solution from blog post. After that I've found that it was <article> and some other stuff.
If you about "you shouldn't be storing generated files in a VCS anyway" then that's outdated. You MUST store all your files that you may want to debug one day in VCS. Broken DOM model may affect JS, styling, further processing scripts and you won't probably want to search for that old version of DocBook template when everything worked ok. More than that - you will probably also need tools that were used to produce this old version. FOP 0.9x doesn't understand old DocBook templates, you know.
Only my former experience with DocBook allowed me to find the solution and apply it quickly. I just thought that having consistent ids by default could help many people without knowledge of XSLT who uses default DocBook generated files as sources for further processing with their language of choice.
I actually accepted suggestion in comment #7 for myself long ago. =)
I checked in a change similar to what was suggested here. I added a new parameter 'generate.consistent.ids', which is set to zero by default. When set to 1, will use xsl:number to create a consistent id if the document structure does not change.