Design for Bug # 1897542

What user need will be met by this feature?

Users needn't worry about their topic ids conflicting with other's. Duplicated topicIDs betwwen different dita files are handled automated by Chunk module.

What is the technical design for the change?

@chunk attribute in <topicref> has seven different values, but only the vaule of to-content need to be considered according to the specification. "to-content" chunk several dita files or topics into one certain dita file, if there are duplicated topicIDs in them, they should be changed.

<topicref> can be nested, and each nested <topicref> can have its own @chunk, in this situation the nested <topicref> are chunked into its own file, not conflict with the ancestors, this brings some difficulties in implementing this feature, fortunately we can use the same idea of nested <topicref> to process the problem of duplicated topicIDs, that is recursion. 

Use a hashset to store topicids which are chunked into a certain ditafile, if there are duplicated topicids, subsitutes it with random generated id. In the case of nested <topicref> with @chunk attribute, construct a new hashset, and preserve the hashset of the parent's <topicref>, restore it after processing current <topicref>.

What sections of the toolkit will be impacted by the change?

ChunkTopicParser.java is impacted by this change.

See also

none