[oXygen-user] [ann] oXygen 11 beta

[ekimber]

On 9/16/09 10:56 AM, "George Cristian Bina" <> 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.

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.

>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.


Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:   <mailto:>
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>