Re: Keyref/conkey ref conversion strategy - keyref all the things? #conref
The problem I see with the convenience feature you're requesting is that it makes your key references dependent on the particular file (storage) organization of the topics, not on the map structure, which provides a layer of indirection between references from topics to keys and the storage details of the target resources. It would also result in ambiguity about the intended target of the key reference.
That is, a keyref like "my-gloss-group/gloss-entry-one" (where " gloss-entry-one" is the ID of a topic) would only work as long as the target topic (the one with the ID "gloss-entry-one") is a literal child of the topic bound to the key "my-gloss-group".
It would also be ambiguous with a keyref to an element *within* the topic with the ID "gloss-entry-one" (which would be valid per the DITA spec if otherwise ill advised). But there would be no way for a processor to know, from the keyref itself, whether the intended target was a topic with the ID "gloss-entry-one" or a non-topic element with that ID within the topic bound to the "my-gloss-group".
Likewise, if the individual glossary entry topics were broken out to their own XML documents, then the keyref would break, which largely undoes one of the values of keyrefs from topics, namely making the reference insensitive to storage details.
As a contributor to the DITA architecture I think I would have to object to the feature request on these grounds alone: it would violate a basic principle of the key mechanism simply to provide a convenience feature that is largely limited to this particular use case.
I'm sympathetic to the need for convenience but it feels like something better handled in the editor rather than at the DITA addressing level.
On 2/19/20, 11:26 AM, "Chris Papademetrious" <email@example.com on behalf of firstname.lastname@example.org> wrote:
It's "easy enough" to write a lot of scripts, but we're starting to accumulate a number of such scripts. I'm not trying to be negative, and I understand why the $key/$elt_id reference structure imposes this constraint. But many of my writers are nontechnical; if I switch from the WYSIWYG view to the XML view in Oxygen, you'd think I'm giving them a sneak peek into The Matrix! And as the champion of our move to DITA, I'm responsible for all automation to hide these sorts of details from them.
In my opinion, having keys map to files is handy, but requiring keys for subtopics in those files is a bit limiting. It would be nice to have the option to use a $key/$subtopic_id reference structure as well.
Enough wishful thinking. It's <glossentry> hrefs for now. Back to work!