Nancy... At 17:21 -0400 27/7/07, ActionA at aol.com wrote:
>A while back I posted some questions about creating a Structured Frame >application so that we can share xml files between Structured Frame and our >XML publishing system that was created in-house. We also have some legacy >material in unstructured Frame that we would need to convert into structured >Frame. Here are some quick answers: others may be able to give you more depth or correct me where I'm wrong. >Since that time, I have completed the XML cookbook and done some playing >around with Frame's conversion table. I have a few questions I thought someone >on the list may be able to help me with: > >1. I'm sure it's in the Structure Application Developer's Guide somewhere, >but what is the correct way to tell the conversion table to wrap all the tags >in a section within a section tag? If I understand your question correctly, construct your conversion tables using qualifiers to nest elements of the same type, working bottom-up. >2. How do element tags get into a Structured Frame template? Are they >created in the template, or are they read in from the EDD? Read in from the EDD. This gives you a choice of where you 'store' them, because once you've read an EDD into a template, you no longer 'need' the EDD until you need to change its structure. I prefer to maintain the structure in the EDD. >3. Why do you define formatting into the EDD? Why not just put that into the >template? Big, big question! Short answer: you don't have to. Long answer: in structured FrameMaker it is possible to include formatting instructions in the EDD itself, to refer out of the EDD to a document's paragraph and character tags using formatting rules, or to use a combination of both. Opinions differ about the merits of each. You can opt to keep all formatting within the FrameMaker document template, by referencing paragraph and character tags from the EDD. However, some formatting operations are simplified by including formatting instructions directly in the EDD. This, for example, allows you to do things you can't do in a template, such as setting relative rather than absolute indents. Keeping all the structure information in the EDD and all the presentation information in the document template means that you can change the visual appearance of content without any need to change the structure definition, which is a plus. Alternatively, you can munge all the formatting information in the EDD. For some applications, this can be desirable. In the end, it's your decision. I'm not experienced enough [have not created enough EDDs] to advise, but there are others on this list who are. >4. Why is the EDD not referenced in the structapps.fm file? Probably because its contents are, or should be, imported into the template that *is* referenced in structapps.fm? >5. We have a schema for our home grown XML publishing system, but not a DTD. >Do I need to make a DTD from that? Can I just use the schema instead? Or, do >I need both? For round-tripping, you need both: FrameMaker uses the DTD to validate the XML that it creates when you save to XML [I think]. Do be aware however that FrameMaker allows you to create element general rules in an EDD that are invalid [too tight] in XML. The workaround for this [thanks, Lynn!] is to conditionalise the relevant general rules in your EDD between FrameMaker [tight] and XML [loose] versions. Here is a simple example: Element (Container): IndexEntry General rule: [FrameMaker version:] IndexGroupTitle, IndexPara* [XML version:] (IndexGroupTitle | IndexPara)* >6. Is there a third-party book I can buy to help me with Structured Frame? Yes: <http://tinyurl.com/36v62c> >Any help would be appreciated. HTH -- Steve
