New

DITA1.3 keyscope support

Tridion Docs provides variable and condition mechanisms to vary contents in a DITA topic. These mechanisms can change the topic contents for each publication. However, when a topic is used multiple location in a map, it is not possible to change the topic contents depend on its context. We would like to unleash this limitation with DITA1.3 keyscope. The keyscope usage example is introduced in the following SyncRO Soft web page:
It seem that Authoring Bridge and Publication Manager do not support resolving keyscope. I expect both client programs to support DITA1.3 keyscope capability.
Naoki Hirai
Parents

  • From the TDUG: we have use cases that would benefit from Docs management support of keyref management. These use cases could ideally be expanded further if keyscopes were supported in addition to keyrefs.

    Linking: using conkeyrefs within links for reuse purposes within super procedures (i.e. "see more information"... within a step of a task), where the super procedure task is used across many publications.

    Also have a preventative maintenance table that would say "Go do this thing..." where the troubleshooting table would be reused, but the specific "Do this thing" topic would be publication-specific.

    Most all use cases for variables would translate over to key-based management and, most importantly, allow for standard-DITA markup that would provide better interchange between third-party DITA-aware tools (translation systems, publishing systems, branch/merge plugins, etc). This furthers  the Docs support of true OotB DITA management.

    We also have potential use cases that would be applicable for keys/keyscopes, but because of no OotB, it's difficult to prototype the business case within the content.

    Ideally, some sort of "Key Management" tab in Publication manager that would mimic condition management could work--have a table with "Key Name" and "Target" to help us manage publications keys and targets. It could also collect all keys used within a publication across all maps/submaps, etc and put them in one spot where they can be reviewed. This view could also be the basis of a simple MVP report about what keys are in the publication, which ones have targets, which ones don't, etc.

Comment

  • From the TDUG: we have use cases that would benefit from Docs management support of keyref management. These use cases could ideally be expanded further if keyscopes were supported in addition to keyrefs.

    Linking: using conkeyrefs within links for reuse purposes within super procedures (i.e. "see more information"... within a step of a task), where the super procedure task is used across many publications.

    Also have a preventative maintenance table that would say "Go do this thing..." where the troubleshooting table would be reused, but the specific "Do this thing" topic would be publication-specific.

    Most all use cases for variables would translate over to key-based management and, most importantly, allow for standard-DITA markup that would provide better interchange between third-party DITA-aware tools (translation systems, publishing systems, branch/merge plugins, etc). This furthers  the Docs support of true OotB DITA management.

    We also have potential use cases that would be applicable for keys/keyscopes, but because of no OotB, it's difficult to prototype the business case within the content.

    Ideally, some sort of "Key Management" tab in Publication manager that would mimic condition management could work--have a table with "Key Name" and "Target" to help us manage publications keys and targets. It could also collect all keys used within a publication across all maps/submaps, etc and put them in one spot where they can be reviewed. This view could also be the basis of a simple MVP report about what keys are in the publication, which ones have targets, which ones don't, etc.

Children
No Data