Arbortext change tracking code breaking DITA build. Any fix?

[sfogel]

Hi, all...

The Arbortext change tracking namespace declaration and <info> element remain in a DITA topic even after you've accepted all changes. The DITA Open Toolkit chokes on the xmlns:atict attribute and excludes the file from the build. Here is the root tag of a concept topic with the offending change tracking attribute:

<concept id="whatever" xmlns:atict="http://www.arbortext.com/namespace/atict">

Does anyone have a workaround? Does anyone think that Arbortext should remove this code once the last change has been accepted or rejected? Thx

Steve Fogel

Information Architect

Oracle Database Information Development

[ptc-4796391]

Hi Steve

I had the same issue few months back with the atict:info element, it did not relate to DITA but different product. As far as I remember I had to use write command with -ct changesapplied which removes the atict declarations from your XML file. Try help center and 'write (command)'.

Regards

Marcin

[BrettMcCorkle]

Honestly, one of the first things I did with our configuration for Arbortext was to disable change tracking, and I haven't looked back. I try to keep our DITA source as free from custom Arbortext tags/code as possible and change tracking puts plenty of custom tags in.

It hasn'tbeen a huge issue for my users, some complained at first, but they've all gotten used to it.DITA topics done right shouldn't be gigantic anyways so figuring out what changed usually isn't a big deal.

Sorry it's not a solution, but maybe asking users if they really need change tracking is a place to start for the time being. PTC should set it up so there's no custom Arbortext tagging left in the file once all changes have been accepted.

One last alternative, you could probably create a custom hook to remove that line of xml from the file when a specific event occurs (like a save). But you'd have to test it to make sure it doesn't remove the line when you still have changes that haven't been accepted.

[ClayHelberg]

Hi Steve--



I don't use the OT, but as far as I can tell, what you've shown below is
perfectly valid XML with a standard namespace declaration. I'm not sure
why your OT tools would choke on that, unless they are using a broken
parser (or an incorrect configuration of a parser).



In any event, you could probably add some code to save without the CT
markup using a doc "save" callback, something like this:



function save_no_ct(doc, op) {

# only work on second call

if (op == 1) {

return 0;

}

# check for actual changes

local CTF_NO_SELECT = 0x4;

local CTF_NO_MSG = 0x8;

local ct = change_tracking_find(oid_null(), 0, CTF_NO_SELECT |
CTF_NO_MSG);

if (ct == oid_null()) {

# no changes, so save without any CT markup

modified(doc, 1);

local CT_APPLIED = 0x02; # save flag

doc_save(doc, CT_APPLIED, doc_path(doc));

# let Arbortext know we handled the save

return -1;

}

else {

# there is at least one actual change, so let Arbortext

# handle the save as normal

return 0;

}

}



doc_add_callback(0, "save", "save_no_ct");



--Clay



Clay Helberg

Senior Consultant



TerraXML

1380 Forest Park Circle, Suite 100

Lafayette, CO 80027

[GarethOakes]

Hi Brett,

Just in case you haven't found the feature yet, you can still figure out what's changed by comparing two versions of the topic using the built-in Arbortext document compare feature.

Cheers,
Gareth

[BrettMcCorkle]

Thanks, Gareth! I honestly haven't looked at that feature closely, but I will next time I need to do a compare. Just shows no matter how long you work with Arbortext, there's always some feature or switch or something burried somewhere that you didn't know about.

In Reply to Gareth Oakes:

Hi Brett,

Just in case you haven't found the feature yet, you can still figure out what's changed by comparing two versions of the topic using the built-in Arbortext document compare feature.

Cheers,
Gareth