At 19:08 -0500 30/5/07, Lin Surasky wrote: >I started by creating an EDD in FrameMaker. It's not particularly fancy, >but it meets the basic requirements for what I need right now. I tried >to save it as a DTD so I could move on to the next step of testing >imported XML. I was getting error messages, so I tested my methods by >creating a new, empty EDD and adding a single simple element (called >"element.") The DTD is saved with no errors, but when I open it in FM, I >get the "Expected comment or CDATA" error and a syntax error. > >Is this a known issue, or am I missing a big step?
I'm guessing here, as I haven't seen your EDD, but here are a couple of things that can snarf up a save to DTD. I hit both of these when I was getting started: . XMl/SGML is foxier about characters in element names than FrameMaker. An element called, for example, '*Thing' will error when you try to create a DTD. Stick to the base character set, alphanumerics, no spaces, for your element names. . XML/SGML is looser in general rules than FrameMaker. It is therefore quite easy to create a general rule in FrameMaker that is invalid in XML, where you are limited pretty much to rules of the form: (#PCDATA | elt1 | elt2 | ...)* The workaround for this, if you need to stick with tight rules in FrameMaker (for example to enforce structure on your authors) is to include both 'tight' [FrameMaker] and 'loose' [XML] content rules in your EDD and conditionalize them: enable the XML versions and hide the FrameMaker versions before you create a DTD. Here are two variants of a general rule from one of my EDDs to illustrate the differences: For FrameMaker: (<TEXT> | IndexTerm | Literal | XRef )*, Graphic For DTD creation: (<TEXT> | IndexTerm | Literal | XRef | Graphic )* You have to write both rules, of course. [Thanks to Lynn Price for the second issue and its fix.] -- Steve
