Errors in dtd element names

[arnor33453439]

Sometimes when we open an XML-file from a book it will not open but generate a lot of errors. I found out that this was caused by the dtd. Some of the element names starting with an upper case are changed to lower case without any reason. For instance "Title" is changed to "title". We did not change the edd or the dtd! If we try to save the edd as a dtd (with the proper names such as "Title"), in the dtd the element name is changed to "title". To make it more strange, this happened only a few times the last couple of years. But is is realy annoying and costs us a lot of time.

[arnor33453439]

Below I've posted two screendumps of the dtd and the edd. Look at the mentioned "title" element. 

[Russ Ward]

Hi. I have no idea if this is related at all, but I want to share something that I have observed. I have noticed that if you have a custom structure definition, but with element names that look like DITA, FrameMaker invokes DITA functionality automatically. That is, it does automatic things that some DITA user might want but anybody else would not want. The <title> element is in the DITA <topic> DTD... which is what makes me think of this.

This aspect of the DITA implementation is very careless and aggravating. It seems to assume that all the world only wants to use DITA, when I'm doubtful of its usefulness in the majority of cases. Because my structure definition looks like DITA in some aspects, I have had to disable all DITA functionality just to make FM work right; that is, like it did before DITA. This includes going into maker.ini to comment out anything that says DITA, especially the API clients. I like FM a lot but have been continuously disappointed by what the DITA fad has done to it.

Russ

[frameexpert]

All good points Russ. The emphasis on DITA has made some novice users think that structure = DITA and that DITA is all there is. One of the strengths of FrameMaker is the ability to create custom structured applications that can be tailored to specific document types and authoring scenarios. Its EDD model, although quite old, is actually quite good. Having an XSLT processor built in is a great feature. But it is surprising how many unstructured users don't know that DITA isn't the only way to go structured.

[Russ Ward]

Agreed on all points Rick. I just wish that the DITA implementation in FM did not think I wanted to use it. If the rest of the world wants to spend their time playing with DITA, fine. But I don't like having attribute values automatically set and other automatic markup changes, just because my DTP has assumed that an element with a name shared by DITA is in fact DITA.

[frameexpert]

One of the unintended consquences of the focus on DITA is that users are leaving FrameMaker for other authoring tools like Oxygen, where the DITA implementation is "simpler" and less expensive.

[arnor33453439]

How can I completely switch off DITA?

[Russ Ward]

I did two things:

- In maker.ini in the Program Files > Adobe > Adobe FrameMaker (version) folder, comment out anything that says DITA. In particular, anything DITA under [APIClients]. This is probably all you need to do.

- In the global application definitions (Structure > Application Definition > Edit Global Application Definitions), either delete or "corrupt" any app definition related to DITA. I had to do this because I use <topic> elements and I did not want my files to trigger the DITA app defs.

Always advisable to make backups of the original files before making any changes.

Russ

[arnor33453439]

Thanks for your advise. I switched off everything related to DITA. Although this didn't solve the problem, I prefer to have switched off unnecessary add-ons. 

[Lynne A. Price · Accepted solution]

I just created a simple EDD that defined two-elements: BrandNew and Title. With no application, I created both an XML and SGML DTD. Both DTDs used the same case as the EDD.

When I encounter the kind of problem you describe, I simplify as much as possible. A simplified application does not need to support all the elements and attributes in the actual application. It doesn't have to work. You have already determined the problem is in the generated DTD. Two areas you can simplify are your XML application and the EDD. What happens if you generate a DTD from a two-element EDD such as the odne I described above? Try one element that appears in the real DTD with the desired case and one in which the case is changed. If you find the problem occurs in the simple test case, check your r/w rules. If you remove the r/w rules from your test application, does the problem still occur? If not restore the r/w rules but remove successive rules from the file to see if there's one that causes the problem.  

   --Lynne

[arnor33453439]

Dear Lynne, thanks for your reply. The problem indeed seems to be caused by the read write rules. I tested it with a simple EDD, with the read write rules disabled it works fine. I have modified the read write rules, everything seems to be working fine now. However, it remains strange that only one of our many projects goes wrong. I can't figure out why. The other projects use the same read write rules....

[Lynne A. Price]

Arnor,

   What change did you make to the r/w rules that fixed the problem in the troublesome project?  

   To pursue this problem, I would look at details such as:

1. What version of FM are you using?
2. Do you get the incorrect result with the original rules if you reboot (better yet, restart) your computer before generating the DTDs?
3. Do you process all projects on the same machine? Same application definitions (probably structapps.fm)?
4. Do you change maker.ini for the different projects?
5. Is there any possibility that there is an inadvertent difference in the rules used by the different projects? What happens if you copy the failing rules to a project that doesn't show the problem.
6. Does the order of element definitions in the EDD or rules in the rules file make a difference?

I would probably start with the working and failing EDDs and make numerous successive changes to the EDDs and rules until I got the same result for both. Hopefully, that will reveal the significant difference. I'd start by deleting rules and element definitions that are not relevant to the problem. The goal would be to reveal the significant difference, not to create a working environment.

Good luck,

   --Lynne