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