Oxygen XML Forum

I am wondering if there is a way to use a secondary Content Completion (cc_config.xml) file. I am needing to distribute customizations to our team and cannot simply overwrite the file in the installed framework folder.
Is there a setting in Options that allows for this?

Hi,

Currently you can override an entire cc_config.xml in a framework extension.
If your framework extension folder has a "resources" subfolder with the custom "cc_config.xml" inside, you can edit your framework extension in the Preferences->"Document Type Association" page and in the "Classpath" list add a reference to the "${framework}/resources/" folder making that reference to be the first in the list, so that it becomes more important than the reference to the "${baseFramework/resources/}" folder.

For Oxygen 23 (Autumn this year) we already worked on allowing a file named "cc_config_ext.xml" to contribute a content completion extension, to contribute extra rules to the base "cc_config.xml" eliminating the need to copy the entire "cc_config.xml" from the base to the extension framework.

Regards,
Radu

Thanks, Radu -very helpful! And I look forward to Oxygen 23

Hi,

We released Oxygen 23 and it should contain the improvement I mentioned, a " cc_config_ext.xml" file gets merged with the base "cc_config.xml".

Regards,
Radu

I just stumbled across this feature today. Thank you for implementing it! I've converted our full cc_config.xml file to an incremental cc_config_ext.xml file.

Hi Chris,

I'm glad you enjoy it, honestly I needed it myself for the DITA Map 2.0 support (the DITA 2.0 frameworks extend the base DITA frameworks) so this is why I implemented it

Regards,
Radu

We created our cc_config_ext.xml but we seem to have some merge issue with the base cc_config.xml file. These 2 elements specifically, codeblock and object, where the attributes outputclass and type (respectively) are not getting populated.

Other elements such as table (colsep and rowsep) are working fine.

Thanks,
Alice

Alice - which behavior is not getting applied, the ones in the baseline cc_config.xml file in the framework, or the ones in your incremental cc_config_ext.xml file?

I have noticed that if there are multiple <elementProposals> that apply to the same element, the last one wins even if they are configuring different things. For example, in this:
In our case, both specifications were in our cc_config_ext.xml file. However, the second specification caused the first specification applied to <li> to be discarded, which caused me some confusion when the specification didn't get applied.

(To Syncro Soft - it would be a nice enhancement to override per-attribute instead of per-<elementProposals>. Oftentimes, insertElements is applied individually to elements, whereas rejectElements can be applied to groups of elements, and it is cleaner to keep these specifications orthogonal.)

The attribue values for codeblock that were set in the baseline cc_config.xml are not getting applied.
We don't have anything for codeblock in our incremental cc_config_ext.xml file.

From baseline cc_config.xml, a snippet of the codeblock setting:
Also, the attribute values for table are applied (from baseline cc_config.xml) which is inconsistent with codeblock.

I tried copying the baseline cc_config.xml to same folder where we have our incremental file to see if that will work. And
on the Classpath tab, I moved it ahead of the baseFramework/resources to make sure it's the one that's called first.
This still didn't fix the issue.

Hi Alicia,

I'm afraid I cannot reproduce the problem, please try to minimize the contents of your "cc_config_ext.xml" file until the problem goes away, comment out sections from it, maybe you do have some selector there interfering with this and you will learn more about what causes the problem. Or send us your "cc_config_ext.xml" file via email (support@oxygenxml.com) in order to reproduce the problem on our side.

Regards,
Radu

Thanks Radu!
I did as you said and was able to isolate the sections that was causing the issue. The sections I placed comments on don't seem to have any interfering selectors. I'm sending you the files in the support email you provided.

Regards,
Alice