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


Reply via email to