On 9/16/09 10:56 AM, "George Cristian Bina" <george@oxygenxml.com> wrote:
Hi,
DITA 1.2 support ================ Some of the new DITA 1.2 features are supported. These include insertion and visualization in the Author mode of conref ranges and conkeyrefs, insertion and navigation for keyrefs in the context of the current DITA map.
From an integration API standpoint I would want to have a "key definition
Support for keyref very nice: the DITA 1.2 spec uses keyref heavily--nice to be able to navigate all the xrefs in the editor now! 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. 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. 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. 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. Cheers, E. ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>