Automatically set @keys attribute for new topics

Are you missing a feature? Request it's implementation here.
chrispitude
Posts: 326
Joined: Thu May 02, 2019 2:32 pm

Automatically set @keys attribute for new topics

Post by chrispitude » Mon Mar 09, 2020 9:05 pm

An increasingly common DITA best-practice is to define @keys values for all topic references, then use keyrefs instead of hrefs for references to topics and their contents.

Currently, users must remember to set the @keys value each time they create a new topic in the map. This is error-prone.

It would be great if Oxygen could provide an option to set this automatically:
new_topic_keys.png
new_topic_keys.png (36.66 KiB) Viewed 1342 times

Radu
Posts: 7469
Joined: Fri Jul 09, 2004 5:18 pm

Re: Automatically set @keys attribute for new topics

Post by Radu » Tue Mar 10, 2020 10:22 am

Hi Chris,

Thanks for the suggestion, based on a previous request of yours we have an issue logged with ID EXM-40196.
We'll update this forum thread when the issue is implemented.

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com

sorin_carbunaru
Posts: 363
Joined: Mon May 09, 2016 9:37 am

Re: Automatically set @keys attribute for new topics

Post by sorin_carbunaru » Wed May 20, 2020 12:30 pm

Hello Chris,

It's been done in Oxygen 22.1. You can find some more info at https://www.oxygenxml.com/doc/versions/ ... opics.html (look for Use the file name as the value of the "keys" attribute for topic references).

Best wishes,
Sorin Carbunaru
oXygen XML

chrispitude
Posts: 326
Joined: Thu May 02, 2019 2:32 pm

Re: Automatically set @keys attribute for new topics

Post by chrispitude » Tue Dec 08, 2020 9:37 pm

Hello! We're using Oxygen v23. (Impressive release, by the way!)

I noticed something interesting today. The DITA > Maps > Use file name as the value of the "keys" attribute setting affects <mapref> elements as well as <topicref> elements. For example, if I add a peer map reference (@scope="peer", @processing-role="resource-only", @keyscope defined):

image.png
image.png (10.42 KiB) Viewed 948 times

then the resulting <mapref> also has @keys defined:

image.png
image.png (3.93 KiB) Viewed 948 times

which I can confirm by going back into Edit Properties:

image.png
image.png (7.16 KiB) Viewed 948 times

But even if I delete the mapref's @keys value there, it gets recreated when I exit the Edit Properties dialog.

I understand the use of having a topicref with @keys, but not a mapref with @keys. Is this a useful behavior to have? What does it allow me to do? Is it harmless, or could it cause an unintentional key namespace collision?

Thanks!

sorin_carbunaru
Posts: 363
Joined: Mon May 09, 2016 9:37 am

Re: Automatically set @keys attribute for new topics

Post by sorin_carbunaru » Wed Dec 09, 2020 3:45 pm

Hi Chris!

The <mapref> element is, in the end, just a convenience element that is equivalent to a <topicref> with the @format attribute set to "ditamap". Therefore, I would say it's normal for the <mapref> to also get a @keys attribute, just like other references do. You can later use the key name to refer the map using @keyref. And I don't think it's harmful.

In regards to the fact that you cannot remove the key using the "Edit Properties" dialog, I am afraid I cannot reproduce this behavior... After I click OK, the @keys attribute is removed.

Best wishes,
Sorin Carbunaru

chrispitude
Posts: 326
Joined: Thu May 02, 2019 2:32 pm

Re: Automatically set @keys attribute for new topics

Post by chrispitude » Mon Dec 21, 2020 4:18 pm

Hi Sorin,

I found that the key is removed if you delete it and hit OK, but it comes back if you go back into the editing window and make some other change (or even nothing, as shown below) then hit OK:

key_redefined.gif
key_redefined.gif (153.64 KiB) Viewed 813 times

If this is a bug, it's a very minor one. I'll leave it to you to decide whether you want to file it. This behavior is not causing us any issues.

sorin_carbunaru
Posts: 363
Joined: Mon May 09, 2016 9:37 am

Re: Automatically set @keys attribute for new topics

Post by sorin_carbunaru » Mon Dec 21, 2020 5:30 pm

Hi Chris,

Now I am able to reproduce the bug. Thank you for the info! I created EXM-47008 :).

All the best,
Sorin C.

Post Reply