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

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

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

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

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>

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).