[oXygen-user] [ann] oXygen 11 beta

[Radu Coravu]

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