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
b...@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
