[oXygen-user] 10.3 DITA Editor Behaviors

[Coravu Radu]

Hi Eliot,

See some answers below:

Eliot Kimber wrote:
> I'm using DITA 10.3
>
> - The ID generator is nice but it would be nice if it generated much shorter
> IDs. It looks like it's generating UUIDs but in most cases it would be
> sufficient if the generated ID incorporated the ID of the root topic and a
> shorter value, such as a 5-digit serial number. Since IDs for elements other
> than topics only need to be unique within their containing parent topic,
> there's no need for long or globally-unique IDs (and there shouldn't *ever*
> be a need for such IDs, but I realize that some CMS systems impose that
> requirement).
>   
We wanted to make sure the generated IDs are unique throughout the 
document. Checking through the entire document each time a new element 
is inserted/pasted is not a great idea if the document is large. I know 
this is not the case for DITA but the support is generic also for other 
frameworks like Docbook, TEI where the documents can grow quite large.
The ID generator is part of the Author API and you can re-generate the 
DITA framework to generate your own IDs. I can give you more details on 
this if you are interested.
> - The ID generator does not modify IDs on copy--that means if I create a
> topic within a parent topic and then copy it, I get a "duplicate ID"
> validation error and have to go manually fix the ID. Copy (as opposed to
> move) should act like create and assign a new ID. If Oxygen can't reliably
> distinguish move from copy then the current behavior is better than
> resetting an existing ID value.
>   
We considered to never alter an already existing ID value and only 
generate for ID values which are not set or empty.
I think you can create a "Duplicate Topic" custom author action which 
would first copy the XML for the current topic, remove the ID and then 
insert it after the current topic.
I can give you more details on this if you are interested.
We'll also try to add some quick fix support in a future version.
> - The behavior of the insert topic ref dialog when you select "append child"
> is to continue appending children, so if you keep the dialog open after
> doing say "insert topicref to currently-edited file" and don't change the
> insertion location, the next topic inserted is inserted as a child of the
> one you just inserted, which is almost *never* what I want. In almost every
> case that I've inserted a topic and then want to insert more, I'm inserting
> children of the initial parent topicref that all exist in the same directory
> as the topic I just inserted.
>
> That is, I think it would make more sense for the dialog to *always* revert
> to "insert after" behavior even if the origin insertion was an "append
> child" insert.
>   
Indeed the current behavior is sometimes annoying, we'll fix this 
probably as you suggested.

Regards,
Radu