Why Read/write rules and round tripping?

[annette_b]

Hello,

I'm planning to set up a documentation project using DITA and I'm evaluating which editor would be better. I don't know Framemaker and one of the things I don't understand is what are the read/write rules? When do I need them? What does it take to define them?  My output will be PDF files and the content will be translated in more than 20 languages.

Many thanks if one of you can clarify that point for me,

Regards,

Annette

[ScottPrentice]

Hi Annette...

Read/write rules control how elements and properties are modified as files are read (opened in Frame) and written (saved to disk). This is a simple file to create and is just one piece of what's called a "structure application". In order to edit XML files in FrameMaker you need a structure application developed specifically for the XML model you're working with. This basically converts the XML markup into something that Frame can use (as well as controlling the formatting within Frame for PDF publishing), and provides the instructions on how to write it all back to the proper XML markup on disk (this is what's called "round-tripping").

If you're working with a popular model (like DITA) the structure applications are already available for you to use. You'll likely want to customize them from a formatting perspective, but other than that you should be all set. For more info on the files that make up a structure application, you might check out this article on our blog ..

     http://blog.leximation.com/2012/01/framemaker-edd-template-rules-–-what-is-all-that-and-how-does-it-...

We provide a plugin for FrameMaker called DITA-FMx that provides additional DITA features and enhanced publishing options (much easier than default FM DITA support). We have a number of clients who successfully publish to 20+ languages. You might want to ask about this on the dita-fmx-users Yahoo group to hear what's involved. You can read more about DITA-FMx (and download a trial) here ..

     http://leximation.com/dita-fmx/

Cheers,

…scott

Scott Prentice

Leximation, Inc.

www.leximation.com

[Lynne A. Price]

Read/write rules specify options for representing XML documents in FrameMaker. As the name suggests, FrameMaker uses them both to read (open, import) XML documents and to write (save, export) XML.

In general, when FM imports or exports XML, an element in one view corresponds to an element with the same name in the other view, and an attribute in one view corresponds to an attribute with the same name. Sometimes, though, an XML attribute specifies information that is innate in FM and hence does not require an attribute in the FM view. For example, XML table representations frequently use an attribute for the number of columns in a table. FM tables don't need an attribute -- tables are composed of rows and columns and the number of columns is an inherent part of that. Read/write rules allow you to identify the attribute used for this purpose and also to indicate which XML elements represent tables and other special formatting objects. Read/write rules can also specify name changes between FM and XML.

Read/write rules can be entered into plain text files or structured or unstructured FM documents. They are documented in the Structure Application Developer's and Reference Guides. See FrameMaker Help for links to these manuals. FM provides a wizard for developing read/write rules (StructureTools > Structured Application Designer) but it doesn't let you copy an existing rule and modify it when you need multiple similar rules. Nor does it support comments.

Read/write rules have not changed much over the years. There's an old template for structured r/w rules available at www.txstruct.com/rules.htm. I need to update it for the new rules that have been added in the last couple of versions of FM, in particular for the new support for using attributes to preserve custom ruling and shading in table cells.

I'll conclude with a brief statement of how read/write rules fit into FrameMaker XML applications. For most XML constructs, including elements and attributes, FM's default processing is sufficient. R/w rules specify context-independent variations. More sophisticated variations can be handled through XSLT or a custom API client (plugin).

    --Lynne