Issue with RE:RootElement and Conversion Table

[Guest]

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...

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

[Van Kurtz]

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

[Guest]

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]

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

[Guest]

Hi Van,

I appreciate your willingness to dig into distant memories to try and find a solution!    Moving the RE specification to the end of the table made no difference, unfortunately. 

I did re-arrange some of the other elements in the table to reflect a low-to-high setup, though, so hopefully that will help prevent any kind of other issues.

Can you tell me - if you were in my spot and couldn't find the answer you needed from either the forums or the published reference materials from Adobe, what would you do?  Is there an escalation path to Adobe somewhere?

Regards,

Hannah

[Van Kurtz]

Hannah,

Can you tell me - if you were in my spot and couldn't find the answer you needed from either the forums or the published reference materials from Adobe, what would you do?

I would keep at it until I got it to work. I doubt there anyone at Adobe would help you. This is not a bug issue.

You said that moving the RE line to the end of the table did not help. This may be grasping at straws, but did you apply the conversion table to a document to which you had already applied the conversion table? If so, you should apply it to the original unstructured document. It may sound weird that I would ask this, but I knew someone who did just that.

I looked in the Structured Application Developer REFERENCE for version 9, and found this:

The root element name that you choose should be unique within the document. If you specify a

name that its being already defined for some other object, the root element is ignored. You can

still generate a structured document with the table, but it will not have a valid root element, and

a message is added to the FrameMaker Log window: “Element name defined in second column

of conversion table for root element is not unique. Root element ignored.”

The root element tag should appear only once in the conversion table. If it appears anywhere else

with a different name, it is ignored and a generated document does get a root element, but if it

appears twice with the same name, both elements are ignored and a generated document will

have no root element.

If no root element is generated for a document (either because the conversion table contains no

RE:RootElement tag or because it is not specified correctly), the ‘NoName’ element appears at

the top of the element hierarchy. The rest of the elements are its children, and the hierarchy is

shown to have an invalid structure.

So, check that you have only ONE RE row in the table AND that the element Chapter is used ONLY in the RE line and no where else in the conversion table.

Keep at it,

Van

[Guest]

Hi Van,

I'm sure it's not a bug issue, it's probably something I have done incorrectly...just wish I knew how to identify the error!    I will keep trying.

Meanwhile - I have only one RE row in my conversion table, and the element Chapter is only used in that one row. I have only tried applying this conversion table to the original, unstructured document.

I will try this process on a framemaker sample doc to see if there's anything else that seems different.  Please let me know if you think of anything else to look at.  I appreciate the insights.

Regards,

Hannah

[Guest]

Good, so it seems like the issue is not in the conversion table, but in the unstructured document somehow.  I created a new conversion table on a FM sample file, and converted it with no troubles, even adding the Root Element correctly.

I then copied some of the paragraph styles out of the test conversion table, dropped them into my main conversion table, and used it to convert the sample file from unstructured to structured.  Still worked, still wrapped the document in the root element correctly.  So, I can only assume that the problem is not the way the table is built, but something in the unstructured file I am trying to convert that is causing the RE wrap issue.

No solution, but it feels like progress!

[Van Kurtz]

That's good Hannah.

If you ever figure out what caused the problem, please let us know.

[Lynne A. Price]

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

[Xarandir]

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.

[Sue Thomson]

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!!!