oids management in Arbortext Editor

[pzorrilla]

Hello everybody!

OK, I've been working with oids in Arbortext Editor to implement a navigation algorithm through the document using Java and ACL, the first stage of my project was only related with navigation, however, now I'm making changes in the document, which means, I'm inserting new tags in my docbooks. I'm having a problem which I identified some weeks ago; in order to execute the navigation I generate a map using a list created with java and all I do is navigate through the list, the list contains oids corresponding to every element inside the document, and the idea is to update the list everytime that changes are made in the document, however, I saw that when I insert a new tag the oids of some of the elements change, not only the which one of the modified tag but instedad the following tags/nodes, this force me to REMAP the document, which it wasn't a big problem until I have to execute this navigation several times in another functionality that requires to navigate and change the document several times at one call of this feature from the user. I'm not sure why several oids change even when I only modified one, I've been investigating but I can not find enough information, so I was wondering if anybody here knows more about this oids behavior and how can I handle them in order to avoid extra data processing with my java object.

[ptc-5681790]

Are the changing oids actual document nodes or are they gentext oids? How are you modifying the parent node, only inserting a new oid? Are the modified oids children or following siblings? Are the modifications made using ACL or DOM/AOM?

[pzorrilla]

Hi Steve!

Paulette

[ptc-5681790]

There is an acl oid_type function that returns an int that maps to the oid type you could use. I believe there is an analogous DOM function you can use as well. I've had all sorts of problems with gentext and also xinclude objects that behave inconsistently relative to file entities and also based on view status. This could be a red herring, but those are the issues I've run into with doing oid manipulation in the past.

[ClayHelberg]

Hi Paulette-

Here's one thing you could try: process the OIDs in reverse document order. That way when you modify the last OID in your list, any following OIDs that become invalid due to the change will be beyond the scope of what remain to be processed. Something like this (very simplified):

local oids[];
oid_find_children(oid_root(),oids,"section");
local oid_index;
for (oid_index = count(oids); oid_index > 0; oid_index--) {
# process oid here...
do_something_with_oid(oids[oid_index]);
}

--Clay

[mramshaw]

As a general rule, I would do as much OID work in ACL as you can rather than Java. I had to do a lot of that kind of processing work and ACL was easier and quicker.