• State Suggested Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 138 subscribers
  • Views 3494 views
  • Users 0 members are here
Options

Content Importer configuration file for TD14

Naoki Hirai

The file 'Trisoft.ContentImporter.config' exists in the AppData folder for each user. There are some processing parameters in this file. I'd like to know about the 'validateReferences' parameter. The default setting is as follows:

  <validateReferences>Error</validateReferences>

I think by this default setting, if Content Importer detects link error in maps or topics, those files would not be imported. Is this correct?

In addition, are there any alternative settings for the 'validateReferences' parameter?

If there are alternative settings, please let us know those alternatives with the outcomes.

Kind regards,

Naoki
Rate translation
×
Suggest better translation
×
Parents
  • 0

    Hi Naoki,

    In general you are right. The idea is to avoid "garbage in" because that in turn usually results in issues and essentially "garbage out". Main idea is described on TD14SP1 - Preparing DITA content for conversion and import

    Slightly more technical, engineering sometimes adds flags to allow debugging situations or bypassing certain issues. The configuration permutations that make sense for the wider audience are typically documented and in turn tested.

    Your flag is not documented on TD14SP1 - Trisoft.ContentImporter.config which makes me believe it is an engineering edge case. Looking at the value "Error", I can imagine that there would be a "Warning" or "Info" flavor. Then again that is a technical prediction, the main question is: Why would you need this to behave differently, because there could be side effects if you lower the incoming data quality?

    Hope this helps,
    Best wishes,
    Dave
Reply
  • 0

    Hi Naoki,

    In general you are right. The idea is to avoid "garbage in" because that in turn usually results in issues and essentially "garbage out". Main idea is described on TD14SP1 - Preparing DITA content for conversion and import

    Slightly more technical, engineering sometimes adds flags to allow debugging situations or bypassing certain issues. The configuration permutations that make sense for the wider audience are typically documented and in turn tested.

    Your flag is not documented on TD14SP1 - Trisoft.ContentImporter.config which makes me believe it is an engineering edge case. Looking at the value "Error", I can imagine that there would be a "Warning" or "Info" flavor. Then again that is a technical prediction, the main question is: Why would you need this to behave differently, because there could be side effects if you lower the incoming data quality?

    Hope this helps,
    Best wishes,
    Dave
Children
  • 0 in reply to Dave De Meyer

    Hi Dave,

    I interested in this parameter because:

    In our company, we sometime duplicate a publication after translating it. Because the content of the document varies depending on the product destination and it's difficult to manage those differences completely by using conditions and variables. In this case, though we duplicate maps and topics, same illustrations are used by duplicated topics. To achieve this importing scenario, we need to import topics that refer to illustrations using GUID. However, Standard import of Content Importer refuses topics that have broken links in the file system.

    Kind regards,

    Naoki
  • 0 in reply to Dave De Meyer

    Hi, Dave,

    Rather than start a new post, I'd like to jump on here to ask about one of the other fields: config/processors/dita/ditasettings/convertConditions

    <convertConditions>true</convertConditions>

    If I were to flip this to "false" would that then bypass the conversion of DITA profiling attributes to ishconditions? And only that (don't want to break anything else.)

    As a transformation developer, I've preserved some customer specialization attributes inside @otherprops to assist with round-tripping the content back to the customer doctype when requested. Our authors don't like seeing these as ishconditions in TD14. (Using TD14 SP3) We don't use any of the other profiling attributes in our source, and we don't use DITAVAL, so it shouldn't hurt us to turn this off on import, if possible and not discouraged.

    I did browse the doc, but I'd like to know if changing this line in this file might be discouraged for any reason.

    https://docs.rws.com/806356/704751/sdl-tridion-docs-14-sp3/trisoft-contentimporter-config 

    Thanks!

    -Jay Baldwin
  • 0 in reply to Jay Baldwin

    Hi Jay, did you ever get an answer on this? I would like to do the same thing with a @props attribute.
  • 0 in reply to Mark Giffin

    I can answer my own question now. The answer is yes, you can turn off Content Importer's converting of DITA profiling attributes like @props into Tridion conditions (@ishcondition) by setting a parameter in this config file:

    C:\Users\USER\AppData\Local\SDL\InfoShare Client\14.0\Trisoft.InfoShare.Client.config

    Change the convertConditions parameter to false:

    <convertConditions>true</convertConditions>
  • 0 in reply to Mark Giffin

    Hi, Mark, I did not get an answer; however, I did learn one additional nuance to this. Even when you succeed in disabling the conversion of DITA profiling attributes to ishconditions, those attributes still display in the publication manager preview pane as if they were ishconditions. The magic that controls that is an XSL style file on the server (that syncs to client). 

    \\[server]\InfoShare\Web[suffix]\Author\ASP\Preview\common\infoshare.utilities.xsl

    This is one of the files that controls the styling of the preview pane in TD14 publication manager.

    What I did was remove @otherprops from the set of attribute names that were considered “DITA condition attributes” (not the same is ishconditions).