infotexture // Information Architecture & Content Strategy


WebWorks TopicAlias Marker Changes

One of the nice things about single sourcing with WebWorks and FrameMaker is that you can embed context information in your FrameMaker source files using custom markers, which WebWorks processes when creating context-sensitive help formats such as Microsoft HTML Help.

However, if you’re considering upgrading from an earlier version of WebWorks Publisher to the latest ePublisher platform release (currently version 9.2.2 build #10315), you should be aware of a significant change in the way that TopicAlias markers are handled.

In WWP6, the contents of TopicAlias markers were treated as numeric MapIDs, and WWP autogenerated text aliases based on the text of the heading in which the TopicAlias marker was inserted.

For example, if you inserted 1002 in a TopicAlias marker, WWP6 would generate a mapping entry as follows:

   #define Heading_Text1002  1002 /* Heading Text */

Now in WWeP 9, the contents of TopicAlias markers are instead treated as text aliases, and WWeP instead generates its own map IDs based on the sequence in which TopicAlias markers appear in source files.

In WWeP, the example above is now output as follows:

   #define 1002 10000010 /* Heading Text */

The old approach in WWP6 meant that the map IDs received from application developers could be inserted in TopicAlias markers in a one-time effort, and these IDs were honored regardless of topic order or heading text. If either of these changed from one release to another, WWP handled all necessary changes with no manual rework, as text aliases were created and associated with the proper files automatically.

According to Quadralay, the change was intended to resolve “confusion” regarding the use of TopicAlias markers, since under the new scheme, these markers are indeed treated as text aliases.

However, for users migrating legacy projects from older WWP versions in which TopicAlias markers contained numeric IDs, the distinct disadvantage to this method is that changes to topic order now affect the autogenerated IDs, which requires manual changes to either application source code or manual editing of custom map files.

Workaround: If your fileset contains only a small number of TopicAlias markers, your best bet is probably to bite the bullet and replace the numeric IDs in the TopicAlias markers in FrameMaker with the alias strings from the header file supplied by your application developers (something like IDH_DLG_DIALOGNAME).