Hi Eliot, See some answers below: ekimber wrote:
I notice that the insert keyref dialog only shows the keys descending from the map selected in the map manager. I'm not sure what else you can do, but I think I would like to have the option of setting a "keyref resolution context" for an editing session or a project, which would normally be the root map I'm working under.
In the case of the DITA 1.2 spec, there is a root map and then a number of subordinate maps, each with its own set of key definitions specific to that map (e.g., one for the L&T module, one for the Machine Industry module, etc.).
If I'm editing an L&T topic I may still need to refer to a base element's key, but to do that, I have to explicitly select the master map, not the L&T map (which is where I probably am if I've either opened that initially or navigated to it from the main map before navigating to the topic I want to edit). Not a deal killer, but it means you have to have the map open in order to select keys from it (of course, the editor will have to have processed the map in any case to make keys available, even if it doesn't show it in the map manager).
I could see having the "default key context" be a project-level setting.
We considered the adopted solution (using the current edited DITA Map as the context) as the easiest way to choose/resolve keyrefs without the need for additional configuration on the user part. Indeed in the case of maps which refer other maps it is not always a good solution and requires sometimes opening the master map just so that you can reference a key from its context. We'll try to come up with a way of being able to specify the master-map.
On the other hand, in a large content set you might have 10s of thousands of keys organized into many submaps, so just presenting a flat list of keys will not always be practical. Might be useful to have a tree view of the keys reflecting their organization into maps and submaps. But in that scenario, I can see that showing only the keys in a specific map helps because it implicitly narrows the selection.
The decision to have a flat representation of the list of keys was made because, if my interpretation of the DITA 1.2 is correct, keys can overwrite each other. If the layout has a tree structure maybe the user chooses a key from a sub-map believing it hrefs a location and in fact the key is overwritten in a parent map to point to another location. What do you think about this situation?
In my map specializations I now include a generic "keyset" topicref that simply serves to organize sets of keys within a map. Might be useful to have a key selector reflect any topicref hierarchy and navigation titles used in the map, on the assumption that such groupings must be significant.
Yes, indeed a problem with the flat selector. Maybe a tree table with a third "Navtitle" column would be better.
From an integration API standpoint I would want to have a "key definition provider" extension point so that a CMS could, for example, provide keys without the need to first open a map, so one could edit a topic from the CMS and still create key-based links to things the CMS knows about--I didn't look to see if such an API is already provided.
We have no such thing in the API, yet but it will be discussed.
Cheers,
E.
---- Eliot
Regards, Radu -- Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com