Skip to main content
S
sfogel1-Visitor
1-Visitor
May 21, 2013
Question

Arbortext change tracking code breaking DITA build. Any fix?

  • May 21, 2013
  • 5 replies
  • 1497 views

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

    5 replies

    P
    ptc-47963911-Visitor
    1-Visitor
    May 21, 2013

    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



    B
    BrettMcCorkle1-Visitor
    1-Visitor
    May 21, 2013

    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.

    C
    ClayHelberg18-Opal
    18-Opal
    May 21, 2013
    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
    G
    GarethOakes16-Pearl
    16-Pearl
    May 22, 2013
    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
    B
    BrettMcCorkle1-Visitor
    1-Visitor
    May 22, 2013

    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
    Terms & ConditionsCookie settingsAccessibility statement