FrameMaker and ArborText

Report · Mar 22, 2013

Can two groups within the same company, one using FrameMaker and the other using ArborText, open and edit each other's documents and then bring them back into the original program?

Thanks!

Lisa

Report · Mar 22, 2013

Hi Lisa...

In theory, yes. But it'll depend on the XML model, and will probably require some tweaking on both ends (both tools) to teach each one about quirks added by the other tool.

One common area for trouble is pretty-printed XML. If the Arbortext users pretty-print the XML and that's opened in FM, you'll likely see a bunch of WHITESPACE nodes. If you're using FM11, it'll probably work better, but otherwise you'll need to add an import XSLT to strip the whitespace for editing in FM. Also, different editors use different doctype declarations. FM doesn't like DTD references that are http-based. Also, FM adds some additional header code that is perfectly valid but can be confusing to other editors.

It *can* work, but will take some patience and setup.

Cheers,

...scott

Report · Mar 22, 2013

Thank you for your quick response, Scott!

Report · Mar 23, 2013

Hi Lisa,

I'm currently investigating this very situation.

Historically, the big issue has more to do with the XML parser: some parsers are lax where others are strict when interpreting the spec in gray areas. You need to know where those gray areas are if you're mixing applications. This is true for lots of other programming languages as well and not unique to XML parsers (ask any software development team why they choose a single compiler to standardize their work on).

As to the other issue, Scott's right. Pretty printing can also cause problems. For the record: Arbortext does not pretty print, but it does wrap at 80 characters (historical reasons). However, when it does so, it always wraps on XML-whitespace-irrelavant places (i.e., between attribute values) or at existing whitespace nodes (space between words).

The key thing is to be aware of how different applications treat the underlying files and make sure that any post-processing code that you write isn't depending on let's call it application-specific behavior. (InDesign has a heavy dependence on whitespace.)

I also agree with Scott: I wouldn't try this with anything other than the latest FrameMaker. Adobe has done some amazing work to make it really XML friendly.

Liz