• State Verified Answer
  • Replies 9 replies
  • Subscribers 141 subscribers
  • Views 11130 views
  • Users 0 members are here
Options
Related

Using SubjectScheme to manage ishcondition values?

seth park

Has anybody used DITA SubjectScheme map to manage ishcondition values? I'm having a hard time figuring out how to use Condition Manager to manage conditions at the product team level. Our options seem to be global management or user/local management, with no granularity between.

I think if we had a product-specific SubjectScheme map controlling ishconditions, each bookmap could reference it (as "resource-only", of course) to provide the right amount of consistency among writers.
Rate translation
×
Suggest better translation
×
  • 0
    Rather than exploring SubjectScheme maps, you should look into further information/instructions about Condition Manager. The purpose of that Client Tool is to manage conditions. It provides more conditional processing attributes than the standard DITA set. What confuses you about the Condition Manager for managing conditions at the team level? I can see if I can provide instructions/insight.
  • 0 in reply to Pam Noreault
    Hi Pam.
    Thank you for responding. We understand how the tool works. Our concerns arise from the use and maintenance of the CM tool itself. Only certain user roles have access to the tool. This is also just a single XML file in the system. With hundreds of Authors and other content providers, this will soon become a bottleneck in the content creation life cycle. Users are going to end up just creating local conditions, instead of entering them in the tool. This defeats the purpose of using the tool in the first place. With the SubjectScheme map, local Information Development teams can control their ishconditions and have the same functionality of adding conditions from within the oXygen tool.
    If you have any insight on how other teams are managing the potential for thousands (possible tens of thousands) of conditions using the CM tool, that would be very helpful.
    Thanks!
  • 0 in reply to Craig Zieg
    Hi Craig. I understand what you are saying. One option is to create another role and add that role to all those users who need to use Conditions Manager. The benefit of Conditions Manager is that is gives you a WYSIWYG way of creating/maintaining conditions and the enable and disable works within pub manager. That said, I think what you are saying is that Your business goal is Conditions Governance, while allowing your writers the freedom to add conditions to a Subject Scheme map because that can be checked in and out of the repository (as well as versioned/branched). This is an interesting use of Subject Scheme maps and I don't know of anyone who has tried it so apologies that I can't offer up any info there. IMHO only, do a small proof-of-concept and I'd sure be interested in your results.
  • 0 in reply to Pam Noreault
    HI Pam,
    We do have a CM role, but the user also needs to be in the System Management user group. I've tested the use of SubjectScheme maps, and they will work. The ishconditions used do show up in Pub Manager (because they are local). We may have to come up with a solution that will work around the limitations of the CM tool.
  • 0 in reply to Craig Zieg
    Hi Craig,
    Sounds like you have an interesting case here. Tens of thousands of condition values? [shiver] My short answer to your specific question is: no, I have no experience of using subject schemes for managing condition names and values. Nor have I heard of anything similar really. But I have come across - and currently work on - a case where there are thousands of values on the input side (Bill of materials) describing a certain product in detail. Those values keep changing, a lot of them are not relevant from a documentation perspective...long story short, they must not be used as condition values in modular XML. On that side the condition values are rather stable. So, you need an abstraction layer bridging the PDM / CCMS divide. The goal is to take the BOM as input, parse that and translate it into condition values, populate the publishing context and publish, all via API calls. Wonder if there are any contact points with what you are working on?

    You got me intrigued. So as I understand it you have a product-specific subject scheme map, that is mapped to each bookmap relevant to that particular product. Is the idea that there are more generic subject scheme-encoded condition lists above that, which are pulled in automatically? I guess you have a smaller amount of condition names/values on company level, for example. What kind of assistance would authors get to author complex condition expressions (similar to Condition Builder)?

    Joakim | Information Architect | Citec
  • 0 in reply to Joakim Nybäck

    Hi Joakim,

    Thanks for the feedback. We actually do have a solution in place that will significantly reduce the amount of conditions needed in the CM tool and also handles the complex parameters required. Being in the semiconductor industry, you can imagine  the number of conditions needed to describe complex parts. Many of which are derived from the same license plate. We wouldn't expect the need for complex expressions, since we'd be pushing "release ready" content into the CCMS. Which, by the way, is another hurdle we've had to overcome ourselves.

    As far as SubjectScheme maps go; yes, they can be hierarchical.  For example, a reference manual is made up of several block guides that are each publishable on their own. Block guides are also shared among one or more reference manuals.

    Here is a quick demo of SubjectScheme maps from Oxygen: https://www.oxygenxml.com/demo/DITA_Subject_Scheme.html

    Here is my brief example. You''ll notice that the product subjectDef is commented out, therefore nothing in the product section will be available to choose as a condition.

    <?xml version="1.0" encoding="UTF-16"?>
    <!DOCTYPE subjectScheme PUBLIC "-//OASIS//DTD DITA Subject Scheme Map//EN" "subjectScheme.dtd"[]>
    <?ish ishref="GUID-4C25FB31-713F-46FF-8EF3-3305CB7D304B" version="1" lang="en-us"?><subjectScheme id="GUID-4C25FB31-713F-46FF-8EF3-3305CB7D304B" xml:lang="en-us">
    <title>Subject Scheme map</title>
    <!-- Pull in a scheme that defines audience values -->
    <subjectdef keys="audience">
    <subjectdef keys="audience=therapist">
    <topicmeta>
    <navtitle>Use this for a Therapist</navtitle>
    <shortdesc>This is to be used when needing a Therapist</shortdesc>
    </topicmeta>
    </subjectdef>
    <subjectdef keys="audience=oncologist">
    <topicmeta>
    <navtitle>Use this for an Oncologist</navtitle>
    </topicmeta>
    </subjectdef>
    <subjectdef keys="audience=surgeon">
    <subjectdef keys="audience=neuro-surgeon">
    <topicmeta>
    <navtitle>Use this for a Neuro-surgeon</navtitle>
    </topicmeta>
    </subjectdef>
    <subjectdef keys="audience=plastic-surgeon">
    <topicmeta>
    <navtitle>Use this for a Plastic-surgeon</navtitle>
    </topicmeta>
    </subjectdef>
    </subjectdef>
    </subjectdef>
    <!-- Pull in a scheme that defines product values -->
    <subjectdef keys="product">
    <subjectdef keys="product=P4080">
    <topicmeta>
    <navtitle>Use this for an P4080 product</navtitle>
    <shortdesc>This is to be used when needing an P4080 product tag.</shortdesc>
    </topicmeta>
    </subjectdef>
    </subjectdef>
    <!-- Define an enumeration of the audience attribute, equal to
    each value in the users subject. This makes the following values
    valid for the audience attribute: therapist, oncologist, physicist, radiologist,
    surgeon, neuro-surgeon and plastic-surgeon. -->
    <enumerationdef>
    <attributedef name="ishcondition" />
    <subjectdef keyref="audience" />
    <!--<subjectdef keyref="product"/>-->
    </enumerationdef>
    </subjectScheme>
  • 0 in reply to Craig Zieg
    Hi Craig. Thanks for sharing your implementation with the community and my first inclination was to shiver at the number of conditions too. I was glad to hear that you are looking to consolidate as well as manage. I suspect that if the number of conditions continued to grow, you'd hit a point of diminishing returns. Having purchased a couple CCMS tools in the past, determining "must haves" versus "nice to haves" is always a challenge. Kudos to you for using DITA to think outside of the box. Regards - Pam
  • 0 in reply to Joakim Nybäck
    Hi Craig,

    I have the same issue. Did you find any solution around managing 'local' conditions?

    Thanks,
    Pankaj
  • 0 in reply to Pankaj Lanke
    Sorry for butting in here when you asked Craig, but could you say a few words about what you mean by 'local' conditions?