Solved: Re: Use of ditaval files in Arbortext 6.0

respey · ‎Jul 08, 2015

We make extensive use of DITAVAL files in the documents for our product family. I am looking for a way for writers to be able to specify a value from a DITAVAL file on an element in a DITA topic.

If I look at the Profiling tab of the Modify Attributes dialog on an element, the otherprops field is a selection field; it is not editable. Therefore, we seem to have only 2 options:

Edit the DITA topic in an ASCII editor to add otherprops="xxxx" to an element, such as a paragraph element. I really do not want writers to edit DITA topics in an ASCII editor; that leads to all kinds of issues. 🙂
Modify the ditabase.pcf to add the values specified in the DITAVAL file. This is an issue, especially if writers are working on multiple products. Each product has a completely separate set of DITAVAL values and they are not necessarily related.

If the otherprops field in the Profiling tab was editable, that would seem to solve the issue because we could add the value (and specify the DITAVAL file to be used when we processed our document.

I am relatively new to using PTC Arbortext, so I hope that I am missing a simple solution?

DavidA.Helfinst · ‎Jul 09, 2015

Do you still want to use controlled values in your profiles?

If not - my suggestion would be to go into the base .dcf files and change appropriate attributes in the AttributeOptions profiling attributes to be @profiling="no". You should then change the "ModifyAttributeCategory" for profiling to explicitly add "audience, otherprops, platform, and product" to that category as the editor will no longer put them in the profiling tab automatically as they are no longer set to be profiled.

If you would still like to use controlled values, then you should do things a little differently by creating and using a "modify_tag" callback. I prototyped one real quickly and what I did was made the profile attributes read-write while still keeping the profiling icons if I wanted to do something that way. You need to do a little more work as the hooks to notify the OK button that something changed is not hooked up to these attributes, so creating a callback on the "OK" button was also necessary. The good thing about this is that it should be possible to check the entered value against list of allowable values and reject items that don't conform.

As you are aware, the great thing about controlled values is that you can't "fat finger" a value, and long values are spelled correctly with the right upper/lowercase. That is why I do like the 2nd approach.

I would be happy to share the prototype, understanding that it is just that, and provided as-is with no guarantees 🙂

Of course, I failed to mention you could use "mt otherprops=newvalue" on the command line!

Hope this helps.

View solution in original post

DavidA.Helfinst · ‎Jul 09, 2015

Do you still want to use controlled values in your profiles?

If not - my suggestion would be to go into the base .dcf files and change appropriate attributes in the AttributeOptions profiling attributes to be @profiling="no". You should then change the "ModifyAttributeCategory" for profiling to explicitly add "audience, otherprops, platform, and product" to that category as the editor will no longer put them in the profiling tab automatically as they are no longer set to be profiled.

If you would still like to use controlled values, then you should do things a little differently by creating and using a "modify_tag" callback. I prototyped one real quickly and what I did was made the profile attributes read-write while still keeping the profiling icons if I wanted to do something that way. You need to do a little more work as the hooks to notify the OK button that something changed is not hooked up to these attributes, so creating a callback on the "OK" button was also necessary. The good thing about this is that it should be possible to check the entered value against list of allowable values and reject items that don't conform.

As you are aware, the great thing about controlled values is that you can't "fat finger" a value, and long values are spelled correctly with the right upper/lowercase. That is why I do like the 2nd approach.

I would be happy to share the prototype, understanding that it is just that, and provided as-is with no guarantees 🙂

Of course, I failed to mention you could use "mt otherprops=newvalue" on the command line!

Hope this helps.

DavidA.Helfinst · ‎Jul 09, 2015

I should have mentioned one more thing.

"profiledochook" is a way to use an alternative .pcf file vs. the one in the .dcf. If your users are switching to docs with different profiles, you could keep the controlled-values and have them choose which one to use as part of the doc_open or such.

One more thing to think about.

respey · ‎Jul 10, 2015

David,

Option 2 sounds like exactly what I am looking for! I would love to get access to your prototype. I agree that it is "as is," but it would help me get started. (respey@Lenovo.com).