Topic level reuse in concatenated DITA maps

[Jeff_Reynolds]

Hi folks- I'm looking for some advice on how to break up a content set

My original map served several audiences and I need to break it into several personae specific guides with some overlapping content.
My problem is when I concatenate the guides I break the search

Any tips?

Original Master Map
Topic 1
Topic 2
Topic 3
Topic 4
Topic 5

New Master Map
User Guide
Topic 1
Topic 2
Topic 3
Admin Guide
Topic 3
Topic 4
Topic 5

[marius]

Hi,

There should be no issue with a structure like the one you posted.
I'm not sure what you mean by breaking the search, however when you perform structural changes to the ditamap you should clear the output before starting a new transformation.
Can you perform another transformation with the clean.output parameter set to yes and see if your problem still persists?
Otherwise we need a complete valid ditamap sample (with the topics included) to reproduce the issue.

Regards,
Marius

[Jeff_Reynolds]

What I mean by breaking the search is that in this example it would only find the first instance of topic three. I'm guessing that I will need to conref a lot of content to make the topics unique and ensure that topic 3 occurs in search results as two distinct topics with different navtitles.

[chrispitude]

Hi Jeff,

In your output directory, do you have a single version or multiple versions of your multiple-instance topics?

[marius]

Hi,
The current implementation of the search engine groups the results from a topic with multiple references in a "Similar results" section.

image.png

Can you see such a section in your case?

[Jeff_Reynolds]

Hi Folks,
Thanks for your responses, I appreciate your interest and support.
I do get a topic generated for each instance of the topic in the build.
I do get the first instance as the primary search return, and the remainder under related links.
I was hoping to find a way to make the content of each submap mutually exclusive, so that if I am searching Map 1, returns are Map 1 topics only.

That isn't happening now, of course...

[chrispitude]

Hi Jeff,

When you say the other topics are shown as related links, are you referring to the "Similar results" list that Marius showed?

Are you looking for search to show only the results inside the book that the current topic belongs to, when the search bar at the top of that topic page is used?

If the search is performed outside the scope of a book, such as from a WebHelp collection's main page, would you expect all books to be searched?

[marius]

Hi Jeff,

The search engine collects and presents results from all topics found in the main ditamp. There is no way at this moment to restrict the search scope to a specific chapter of the main publication.
It is indeed a nice feature and we have it already in our Road Map. We'll try to prioritize it.

Regards,
Marius

[chrispitude]

Hi Marius,

Can you let us know the issue ID for the scoped search enhancement?

[coryc]

Hi Chris,
If I'm looking at the right thread, it's WH-2972.
-coryc

[Jeff_Reynolds]

Yes, "similiar results"....

Thanks everyone again for responses, looking forward to scoped search..

[coryc]

Hi Jeff,

As Marius said, this is a feature they've been working on, and which we've been eagerly anticipating. Since it was a hard requirement for us, we went ahead and implemented a custom solution to meet our needs in the meantime.

This is how our implementation looks to the user. Note the additional <select> to the left of the search <input>:

(Unfiltered search results)

image.png

(Choosing “scopes” for search filtering)

image.png

(Filtered search results)

image.png

Our implementation includes custom XSLT processing to identify and collect scope information at build time, which is used by custom JavaScript when the WebHelp is loaded into a browser. Here’s how I described the way in which scopes are identified. (It equates to the first two levels in the publication-level TOC.)

Scopes are created at two levels. Level 0 consists of <topicref> or <mapref> elements defined in the DITAmap file passed to the Responsive WebHelp transformation. Level 1 consists of <topicref> or <mapref> elements defined in each reference from level 0, if any are present. In usage, <maprefs> are typically to DITA bookmaps.

Is this similar to what you’re asking for?

This functionality has some restrictions and assumptions behind it that are specific to our DITA environment, but I’ve shared the code for the solution with SyncRO Soft in hopes it will aid them in providing a standardized solution that we can eventually adopt.

-coryc

[Jeff_Reynolds]

Thank you!

[chrispitude]

As Cory mentioned (I work with him!), our WebHelp maps instantiate bookmaps in a consistent way and our in-house solution expects that.

For a generalized solution, customers would need some kind of control. Maybe WebHelp could look for the presence of @outputclass="wh_scope" properties (or something similar).