Skip to main content
November 1, 2011
Question

Issue with RE:RootElement and Conversion Table

  • November 1, 2011
  • 3 replies
  • 2293 views

Hi there,

I am trying to convert unstructured to stuctured documents using the conversion table.  I'm building the prototype table and EDD that my department will use, and working in FM 10. Ideally, I'd like to get it to the point where all anyone else has to do is apply the table, but I'm having some issues.

Even though I specify that RE:RootElement should be wrapped in the element Chapter, nothing happens.  My documents come out wrapped in the no-name element, and I have to change them manually to get them to behave.  Any ideas if this is a known issue, or if there is a different way I should specify things, or something else I should write into the EDD?

I followed the instructions in RJ Jacquez's video here: http://tv.adobe.com/watch/structured-authoring-xml-and-dita/migrating-to-structured-framemaker-using-conversion-tables/

I've checked the Structured Applicaiton Developer's Guide for FM 9.0 (http://help.adobe.com/en_US/FrameMaker/9.0/StructuredDev/Structure_Dev_Guide.pdf) but cannot seem to find one for FM 10.  Not sure if that makes a difference.

Any ideas would be welcome!

Regards,

Hannah

This topic has been closed for replies.

3 replies

Xarandir
Participant
August 24, 2015

Hi, this is an old topic but if someone stumbles upon it (like I did in search for an answer): it seems that the trick is to first add the structure, then import the element definitions. First importing the element definitions generates the NoName error.

Participating Frequently
November 13, 2018

Thanks, Xarandir

I have been struggling with exactly this issue in FM2019. I knew I had it working in earlier versions and couldn't work out what I was doing differently.

As you said, you must apply "Structure Current Document" command BEFORE importing Element Definitions.

As soon as I did it in this order, everything worked! Yay!!!

Inspiring
December 17, 2011

Hannah,

  Have you tried to convert more than one unstructured document? Does the problem occur with them all?

  A debugging technique that is often useful is to simplify and shorten both the conversion table and the unstructured document as much as possible.

  For example, does removing all tables from the document make a difference? If not, remove the rows pertaining to the tables from the conversion table. And if the behavior changes as you simplify, take a close look at the last change you made.

     --Lynne

Van Kurtz
Inspiring
November 1, 2011

Hannah,

When you apply structure to an unstructured document with a conversion table, the root element should be set according to the conversion table. In your case, the root element should be Chapter. It has been a long time since I have used conversion tables, but I tried mine on an old unstructured document and it worked as expected.

Where does the no name element appear? When you create a book file and add structured documents to it. The root elements of the individual documents typically display as no name elements. Updating the book usually clears that up.

Let's be clear. Applying structure with a conversion table has nothing to do with the EDD; the EDD is not part of the conversion table. The conversion table just APPLIES structure. Once the structure is applied, you need to import your template (formats and element definitions) into the document. So, there is nothing for you to do in the EDD that will fix the no name elements.

A bit of warning: unless your unstructured documents have been tagged very well, the resulting structured document will likely NOT be perfect with just the application of the conversion table. There is usually some clean up to do after.

Good luck,

Van

November 1, 2011

Hi Van,

You're right - I probably shouldn't have mentioned the EDD, as it doesn't relate directly to the issue. Although, I have found that I can import the element definitions into the unstructured template, where they sit dormant until conversion to structured - so no need to reapply afterward. Since we will be converting many of our legacy documents from Word > Unstructured FM > Structured FM > DITA Structured FM, anywhere I can save some steps, I'd like to.

I can appreciate that there is usually cleanup to do in any conversion, but I'm trying to keep it to a minimum as much as possible. I hope to ease the burden on the other writers who will have to go through this process and don't get as excited as I do about the nitty-gritty details of how things work. 

That said - can you show me how your conversion table is set up? What version of FM do you work in?  If it works just fine for you, there must be a difference between what you've done and what I've done.

Here is what I have:

The no-name element appears in the actual document that results, like so:

In this scenario, I am just running conversion tests on individual files within a book, and the NoName element appears at the root level of the individual file, so I don't think the book update will be of help yet. Once I do put these files back into the book they belong in, a book update will remove the NoName element at the book structure level - but only if the files have correct root elements to import.  Right?

Regards,

Hannah

Van Kurtz
Inspiring
November 1, 2011

Hannah,

As I said before, it has been a long time since I created my conversion table. So, what I am about to say is more recollection than reference to the structured application guide.

As I recall, my conversion table goes from low level to high level. Hence, I first apply character elements based upon character format tags, then apply paragraph level elements based upon paragraph format tags. Then the table looks for collections of elements (eg, Item elements) and wraps them in their container elements; for example, Item elements are wrapped in List elements. Then on up the ladder. My final entry in the table is the root element specification.

Looking at your table, the root element is the FIRST entry. Maybe that is the problem.

Van