OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook] DocBook Assemblies, IDs, and a proposal

Hi Thomas,

The issue of duplicate IDs was discussed during the development of assemblies. We did include one feature to handle the top-level ID of a topic. If you put an xml:id attribute on the module element in the assembly, then that value will replace the native xml:id value from the resource after assembly. That can take care of the top-level id only. We acknowledged that IDs on descendants are not affected, and would likely need an ID fixup process. We did not include that fixup process in the default assemble.xsl because there is no standard way of doing that, so different people will have different policies and methods for doing so. So if you use IDs on descendant elements of topics, we left that as an exercise for the reader. 8^)

I think allowing the trans:* attributes to the assembly schema would provide useful hooks for doing that fixup process during assembly. If you file an issue request on the DocBook Github site, then it will be considered by the DocBook Technical Committee.Â

Before proceeding, I wonder if anyone knows how DITA handles the issue of duplicate IDs?Â

Bob Stayton
On 7/21/2020 5:17 AM, Thomas Schraitle wrote:

DocBook Assemblies[1] contain some great ideas how to write in a topic-
oriented approach in DocBook. The chapter deals with how to reference 
resources, how to combine them, filter them, and output them. This is all 

I really miss some important use case: avoid double IDs.

As far as I can see, this use case isn't covered at all by DocBook Assemblies, 
yet an important aspect. With the current approach it is still possible to 
assemble the same topic multiple times without changing IDs. That would lead 
to invalid DocBook XML.

Was this on purpose? A design decision? Are dealing with same IDs out of scope 
for DocBook Assemblies?

This use case is kind of solved already: Jirka covered this with the DocBook 
Transclusion[2] approach. Basically, it amends the XIncludes with further 
attributes from a different DocBook namespace.

I'm wondering now, if the two approaches could be combined?

So here is my proposal: Wouldn't it make sense to allow the trans:* attributes 
from the transclusion approach inside the assembly RNG schema?

Would that make sense? Do I miss something? Or should the ID fixup be part of 
a post-processing step outside of assemblies?

Thanks for your ideas! :)

[1] https://tdg.docbook.org/tdg/5.1/ch06.html
[2] https://docbook.org/docs/transclusion/transclusion.html

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]