Skip to main content
A
Anonymous
January 27, 2012
Answered

Problem Working With Framemaker 9 Dita XML Files in Framemaker 10

  • January 27, 2012
  • 2 replies
  • 3107 views

I just upgraded to Framemaker 10. I am encountering a number of problems when I try to work with my Dita XML help topics, which were last saved in Framemaker 9 format.

1. Using the Default Dita Template

When I open one of my documents in Framemaker 10, the Dita 1.2 template ditabase.fm is automatically applied. Everything seems fine. But then when I convert the XML to Eclipse help (which is essentially html, so we're going from XML to HTML) using Dita Open Toolkit ant scripts, I see this message:

[pipeline] [DOTJ013E][ERROR] Failed to parse the referenced file 'html\c_licensing.xml' due to below exception. Please correct the reference base on the exception message.
[pipeline] c_licensing.xml Line 25:Attribute "xmlns:ditaarch" must be declared for element type "dita".

I then opened the xml  file in a text editor, and I saw this on line 25:

<dita xmlns:ditaarch = "http://dita.oasis-open.org/architecture/2005/">

Line 25 looks fine to me. Am I missing something? 

2. Switching to a 1.1 Dita Template

I tried to work around the above problem. In Framemaker, I tried to set a different structured application as the default one. I closed all files and chose the default Dita 1.1 structured application (it defaults to the Dita 1.1. Composite app.)

Then I tried to open my file: I got this message inside Framemaker:

"Validation of XML failed. Continue?
Error at [FILE PATH], line 25, char 72, Message: Attribute '{http://www.w3.org/2000/xmlns/}ditaarch' is not declared for element 'dita'

Sounds familiar, doesn't it?

I switched from the default Dita 1.1. Composite structured application to the Dita 1.1. Topic structured application. Then I dirtied the source file and saved it. The messages I got in FrameMaker log window included the one above, plus I got a variety of Unknown Element messages, things like this:

Unknown element dita,

unknown element concept,

various attributes are not declared for concept,

unknown element conbody.

If I switch back to the Dita 1.1 Composite application all of these messages diappear except for this one:

Attribute '{http://www.w3.org/2000/xmlns/}ditaarch' is not declared for element 'dita'


My ant conversion scripts from the Dita Open Toolkit are still unable to process this file. They give the same message as is listed in (1) above and the file is not converted to HTML.


Can anyone help me with this problem? I've also posted this question to the Dita Users Group on Yahoo Groups. If I get an answer in one place, I'll post it in the other.

Thanks,

Nina P.

This topic has been closed for replies.
Correct answer ScottPrentice

[cross-posted to dita-users]

Hi Nina...

The xmlns:ditaarch attribute should be on the "topic" element not the root dita element. if the FM10 structure application is assigning that, it's wrong. Are you creating composite topics (multiple topics in one file under the dita root)? If not, you can get rid of the dita element altogether and that may "fix" the problem.

The first error you're getting (#1) is saying that the xmlns:ditaarch attribute needs to be declared (that is, defined in the DTD) .. it's not (because it's not supposed to be there (as far as I know). It's not saying that it should be declared in the DITA file.

Same for error #2 .. the 1.1 composite app is apparently set up properly, so it's saying the same thing that the OT is saying .. "you've got this attribute in the XML file, but it's not declared in the DTD".

Your later error about missing elements is because you've switched to the "topic" DTD, which doesn't know about the dita element or the concept-based elements.

If you can unwrap the dita element from your files (because you're just using one topic in each file), that may solve the problem. But what you probably should do is open these files in a text editor and remove the xmlns:ditaarch attribute from them (it's not really needed on the topic elements either since it's the default value). Then I'd switch to the 1.1 composite app as your default. I'll take a look at the default FM10 1.2 app and see what's up. (I've not seen this problem since I'm using DITA-FMx which has it's own structure apps.)

Cheers,

...scott

Scott Prentice

Leximation, Inc.

www.leximation.com

2 replies

A
Anonymous
January 27, 2012

Thank you very much, Scott. Removing that xmls:ditaarch attribute from the Dita element worked. The XML document now opens and saves fine in Framemaker, using the 1.1 Composite template.  It also converts to HTML when I run the ant script.

I also tested unwrapping the Dita element from the document. That seemed to work fine as well. The document saved without any errors in Framemaker and it converted to HTML.

I next tried appying the Dita 1.2 ditabase structured app to my source file. It saved properly in Framemaker and the ant scripts did not complain, but I'm going to reapply the the 1.1 Composite template.

Finally, the topics display correcty in the help system.

Not all of my topic files have that attribute in the Dita element, but a good number of them do. Looks like I need to do a bulk search and replace.  Or just remove the Dita element as I open each file.

Was the Dita element once used with older versions of Framemaker?  I am just wondering how it and that attribute got into my source filees in the first place?  I don't recall ever adding it; I think it was always there.

Again, thanks for your help, this had me stumped.

ScottPrentice
ScottPrentice
Inspiring
January 27, 2012

Hi Nina...

I think that the FM templates have always defaulted to creating dita-rooted files. With the Composite (or ditabase) app, you can have it both ways .. which is nice in FM so you only have to maintain one structure app rather than one for each topic type. The reason for using a dita-rooted file is so that you can have multiple top-level topics in one file. If you're not creating files that contain more than one topic, then there's no reason to use the dita element. It's most common to just have one topic per file so in general the dita element isn't used.

Cheers,

...scott

ScottPrentice
ScottPrentice
Inspiring
February 3, 2012

"Your process looks spot-on to me .. and since you're now seeing the app names in the Select Structure App dialog, it now seems to be registered properly.If you're selecting the BigPage app when opening the file, but it's not appearing to be applied, something is still a bit wonky. Unfortunately, the FM10 app mapping process is a bit convoluted and seems to be doing some "magic" on the back end".

Well, this is the weird part. In FrameMaker 10, when I open a topic, I never see the pop-up "set structured app" dialog. That never appears for me, although it always appeared in FrameMaker 9.  Instead, I open my document then go to the Structured Applications menu, and select "Set Structured Application" from there. 

One thing you can do to determine which app has really been applied to the file, is to use the Structure Tools > Export Element Catalog as EDD command.

Ok, opening my test document and trying this. It automatically opens with the wrong structured application selected. So I open the Structure Apps menu, select Set Structured Application, and change the selected DITA1.1 application to a DITA1.1-BigPage  application. The page size does not change, as it should. Then I save the file. Then I export element catalog as an EDD. It says Dita1.1-BigPage-Composite-FM on the exported untitlted EDD, however, despite the fact that the xml file did not change its page size.  If I close this saved xml file and reopen it, export the element catalog as an EDD once again, I find that Dita1.1-Composite-FM is what is on the first line of the exported EDD. It's changed back.

Another test you can do regarding page size is to go in and modify the template for the default FM DITA app. Be sure to back up that tempalte before changing it, but this will be one way to see if there is a fundamental problem with changing the page size.

I did this as part of my "Plan B."  It worked beautifully. The original template is read, and it is tabloid size, so my documents resize to tabloid size.

Your concern about *which* structapps.fm file to use is warranted. In general, you should be editing the one in the "appdata" area. This is the one that opens when you choose the Edit Application Definitions command. However, I have seen a handful of cases where it just isn't working as expected, and you have to copy the one in appdata over the default one in the main FrameMaker program structure. (Be sure to save a backup of the original file.)

Ok, that is covered. Both the structapps.fm files have my "BigPage" modifications now, and I have an original named something else. But it did me no good.

Sorry I can't be of more help. Do let us know what you end up doing!

No problem. FrameMaker 10 apparently works differently than FrameMaker 9 and for some reason will no longer recognize a simple cloned structured application.  I suppose if I dug into the specialization documentation I might be able to figure out why this so, but I've browsed that documentation in the past and it is a bit above my head at this point. I don't have a long time to spend trying to figure it out. 

What I ended up doing was my workaround, described in the earlier message. I modified the original DITA1.1. templates to be "BigPage" (tabloid) size, but left one template, topic.template.fm alone.  I am not single sourcing. My PDF content is separate from my online help content, so this works for me. I found that with a bit of wrapping/unwrapping of various top-level elements and the addition of an ID, I could make my older PDF source files (most were concepts under a DITA element) work well with the unmodified Dita1.1-Topic-FM structured application. I imported my PDF styles into that template as well, and everything looks good. I haven't yet compiled a book, however. If I run into issues at that point (as you suggested I might), I'll post an update. 

---------------------------------------

By the way, a bug cropped up at ID-assignment point. When I added a topic element under my DITA element in a PDF source file, this topic element required an ID.  I couldn't get FrameMaker 10 to automatically assign an ID to a top-level (topic) element I added to the document's structure, even though it was required. Whether or not the Dita Options dialog's "Auto Add IDs if Required By Element" box is checked or unchecked (and the Adobe documentation, paradoxically, says to uncheck it--which seems the opposite what you should do), no IDs are ever auto-assigned to that topic element. I experimented with unchecking the box, adding the topic element, saving the file and getting the "Need an ID" validation message, and then repeating the process with the box checked. I still got the error message no matter which way it was set.  I have to assign required IDs manually. I'll be reporting this  as it does seem like a genuine bug or possibly a doc bug. If there are exceptions to when "Auto Add IDs if Required By Element" works, these exceptions should be documented with the command, but currently no exceptions are listed.

Thank you again for taking all this time,with me, Scott.If nothing else. I've learned a lot more about FrameMaker 10 than I knew when I first posted my question. I'm now a lot more comfortable with the interface and other changes. Also, I believe if I hadn't walked through the broken cloning process with someone else, the workaround wouldn't have occurred to me.


Ah .. if you're not seeing the "Select Structure Application" dialog .. it's still not registered properly. FM10 added an extra layer of processing to this, and I don't recall what it is. It should work, but something is missing. I'll try to mess with this next week and see what I can find.

I don't think the specialization docs will help much, but it's worth a try. It sounds like your "Plan B" is the way to go.

As for the ID issue .. you might check the underlying EDD to see if the @id attribute for that element is *actually* required. Because you're working with multiple apps and multiple EDDs, it may work in one but not in the other. I've not seen that, but that's because I'm not using the default FM10-DITA support.

Cheers!

...scott

ScottPrentice
ScottPrenticeCorrect answer
Inspiring
January 27, 2012

[cross-posted to dita-users]

Hi Nina...

The xmlns:ditaarch attribute should be on the "topic" element not the root dita element. if the FM10 structure application is assigning that, it's wrong. Are you creating composite topics (multiple topics in one file under the dita root)? If not, you can get rid of the dita element altogether and that may "fix" the problem.

The first error you're getting (#1) is saying that the xmlns:ditaarch attribute needs to be declared (that is, defined in the DTD) .. it's not (because it's not supposed to be there (as far as I know). It's not saying that it should be declared in the DITA file.

Same for error #2 .. the 1.1 composite app is apparently set up properly, so it's saying the same thing that the OT is saying .. "you've got this attribute in the XML file, but it's not declared in the DTD".

Your later error about missing elements is because you've switched to the "topic" DTD, which doesn't know about the dita element or the concept-based elements.

If you can unwrap the dita element from your files (because you're just using one topic in each file), that may solve the problem. But what you probably should do is open these files in a text editor and remove the xmlns:ditaarch attribute from them (it's not really needed on the topic elements either since it's the default value). Then I'd switch to the 1.1 composite app as your default. I'll take a look at the default FM10 1.2 app and see what's up. (I've not seen this problem since I'm using DITA-FMx which has it's own structure apps.)

Cheers,

...scott

Scott Prentice

Leximation, Inc.

www.leximation.com

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices