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

[Bob Stayton <bobs@sagehill.net>]

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
bobs@sagehill.net

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

> Hi,
>
> 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 
> good.
>
> 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
>
>