Re: 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
[email protected]

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
>