--- Pedro Pastor <pps at ua.es> wrote: > Maybe the troubles I've found come from my > inexperience developing structured applications in FM, but I cannot fully understand the aim > behind the (so called) "XML-roundtrip" editing. ========================================== Assuming that the documentation you are creating and updating/editing is accomplished by human beings, you can avoid XML-roundtripping only by having your writers create/modify tagged XML. If you expect to have any semblance of a productive authoring environment, you must "round-trip" the XML into some sort of authoring product which provides the numerous bells and whistles needed to hide XML internals from your authors. Most XML editing produces are not WYSIWYG, and thus in those editors authors see something that is not a facsimile of what human readers will see when they retrieve those documents.
Structured FrameMaker is just as much an XML editor as any of the other ones. It provides an automated way to import XML instances into FrameMaker, preserving all the XML internals, and at the end of an editing session, it provides an automated way to export the work product back into fully conformant tagged XML output. The extra feature of FrameMaker is that it avoids the necessity of having to use the clunky and difficult-to-implement XML tools used to accomplish acceptable formatting and layout needed to make documents that are highly readable and effective for human users. That is, FrameMaker, in addition to being a powerul way to create documents, can also serve as a powerful print engine for delivering high-quality, eminently readable, technical documents in paper or PDF format. ============================================== > 1) I cannot understand how to clearly separate > structure from presentation in FM. If EDD contains > structure and presentation > information we are against the main principles of > SGML/XML document > design!! ========================================= Gee, the idea behind FrameMaker is to have the best of both worlds. Desktop publishing systems like FrameMaker have highly sophisticated formatting and layout capabilities. You can, however, completely ignore presentation in an EDD simply by declaring that all text will use a single paragraph style. If, on the other hand, you decide to exploit Frame"s exquisite presentation capabilities, you can export a structured Frame document to XML or SGML, and none of that formatting information gets exported, hence it in no way violates the canons of XML or SGML. The fact is that both SGML and XML provide a set of clunky, insufficient and unwieldy tools for delivering formatted output for printing or on-line display. The FrameMaker EDD offers a far more robust and elegant method for producing high-wuality presnetations. ====================================== > 2) It seems like there are two placeholders > for storing presentation information: Templates and EDD documents. This could be > redundant, I mean, the same presentation definition > data could be store > on both places. ======================================= Again you denigrate a powerful feature of Frame. The EDD specifies the names of paragraph, character and other types of formatting tags based on element context. Templates are used to specify the formatting details for each such tag. There are two advantages to this. First, you can change the formatting (e.g., fonts, sizes, etc.) without disturbing the EDD. Second, you can create multiple template versions for the same EDD, allowing you to deliver differently formatted documents which meet the requirements of different types of users or different types of documents created from the same EDD. Another feature of the EDD is format change lists, which allow certain parameters (e.g., indents, fonr size, autonumbering) of a given format tag to be modified in different structural contexts. =========================================== > 3) In addition to this, Template document > could have structure > associated with it (via importing EDD document). > Then we get just > another way of associating structure to documents, > apart from the DTD > specification!!). ======================================== Wrong again. A DTD contains no formatting information. You create an EDD. Then you import that EDD into an empty FrameMaker document, and the EDD "seeds" the empty document with all the EDD's structure rules as well as all the formatting tags defined in the EDD. Then the designer defines the parameters of each EDD-defined format tag. If your production needs require different presentations for different customers or different types of documents (all created from the same EDD), You create more than one structured template for the same EDD, and design the formatting of each version of the template to meet specific formatting and layout requirements. To create a new structured document, you select the appropriate template file and apply it to a new (empty)FrameMaker file. ========================================= > It seems to me that this roundtrip is trying to > match a mature legacy > product (Structured FrameMaker) with the new > emergent XML technologies, > but it is not intended for XML authoring (as its > main objective). At > this point, (it seems) it is easy to me to produce > XML documentation > (using whatever DTD I'd like) by means of more > "developer-oriented" XML > editors like XML_Spy or Oxygen together with > XSLT+CSS style-sheets then > all the burden of taming Structured FM for this > purpose. > > I'm sure I should have misunderstood something in > this picture, and > that's the reason why I ask for the help of the > experienced FM users. ========================================= FrameMaker, like other desktop publishing systems, provides authors with a WYSIWYG presentation of the information being created. There is no doubt that this approach greatly enhances writer productivity and effectiveness. FrameMaker's structure view, element catalog and other structured authoring aids provide additional productivity leverage. As far as I'm concerned, technical documents output in XML format should never see the light of day outside a database unless it is being delivered to a non-human user. By that I mean you must run the XML through some sort of formatting engine to get something usable to a human reader. The "standard" XML toolset used to produce human-readable documents is pitifully weak and difficult to use compared to what FrameMaker can produce by importing XML instances into a FrameMaker structured application, and, once again, the comparative ease with which a FrameMaker application can be developed further leverages the productivity of a writing group.