You very likely will need this in many cases. However you can come back to this later (this is actually what I suggest). This step must be planned together with See +++ draft +++ Edit the read/write rules file.. anyhow.
FrameMaker has a very good cross-referencing system which is used a lot by typical FM users. To represent cross-references, F+S will produce by default a Xref element (together with a "Reference" attribute) which of course will not be in your DTD. In other words, unless you add a definition for crossrefs in you DTD, your generated XML will not be valid. So in one way or another you must deal with this. Here is an example of an element you could add to your DTD:
<!ELEMENT Xref EMPTY><!ATTLIST Xref href IDREF #REQUIRED link CDATA #FIXED "locator" show CDATA #FIXED "replace" actuate CDATA #FIXED "user">
Warning: Crossrefs to other files will not work. These external links will be resolved to the text string as displayed when you create the link. [Hint from J. Harog: FameMaker understands a 'document' to be anything that lives as a single SGML file (even though, using r/w rules, you may display it in F+S as a book file with several chapters/sections)]. So you have 2 options make a book + r/w rules, or reference to other documents with hand-made links.
So, be aware that managing Crossrefs is a hassle ! Also don't hurry: if you started using Crossrefs in a file without having defined Xrefs in a DTD and without fixing rewrite rules below (see See +++ draft +++ Edit the read/write rules file..), you are in slight trouble, i.e. you have to kill those Crossrefs and enter them again. Dealing with graphics (and even other "weird" elements is also pretty bad.
<!ELEMENT Graphics (#PCDATA)><!ATTLIST Graphics link CDATA #FIXED "locator" href CDATA #REQUIRED show CDATA #FIXED "embed" actuate CDATA #FIXED "auto"><Graphics xml:link="locator" href="graphic3.gif" show="embed" actuate="auto"></Graphics>
Note: When I tried to import an attribute with a namespace (i.e. xml:link) F+S freaked out. Maybe there is solution, but I don't have it (yet) The "real" XML xlink is shown below (for comparison). You certainly can write a XSLT rule to translate Frame's output, but it would be better if I'd manage to configure the SGML declaration to read in elements with namespaces, write translation rules, etc. Postprocessing stinks if you just want to author like you'd author simple HTML, Ideally you say "save" and it's on the web.