[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]
Subject: Re: [FrameSGML] Re: Frame+SGML Tutorial?
From: Marcus Carr <mrc@xxxxxxxxxxxxxx>
Date: Thu, 23 Dec 1999 12:16:18 +1100
Organization: Allette Systems (Australia) Pty Ltd
Is it just me, or is hard to keep track of which forum this thread exists in? Was there really a need to break FrameSGML questions into their own list? Dan Emory wrote: > But there are aspects of EDD design which might make the resulting content > models differ from those that would be used to develop a new DTD. For > example, a graphic element in an EDD cannot have any children, whereas it is > common practice for graphic elements in DTD's to have them. There are also > aspects relating to the formatting of imported tables and cross-references > that are unique to FM+SGML, which often require content models which differ > from those that would typically be used in DTDs. I agree, but I consider them to be shortfalls in FrameMaker+SGML. Of course, that doesn't alter the fact that you have to deal with them > >And one last bit of advice... Authoring in a validated, > >structured environment is different than doing it > >free-form. It takes more effort on the part of the > >authors. > I'd agree with your conclusion in the case where the EDD is derived from a > typical "institutional" DTD. But if more effort is needed in the case where > the structure design was initially done in the EDD, then I would advise > taking another look at the EDD, because it is usually possible to > substantially increase authoring productivity compared to authoring > unstructured Frame docs. That, at least, has been my experience. In many > ways, authoring a structured doc in FM+SGML takes less effort, because > almost all of the formatting burden is removed, allowing the author to focus > on content and structure. Also most authors quickly adapt to using the > element catalog and structure view for guided editing, and like it much > better than trying to create structure with paragraph tags. I agree all the way. The conventional art of designing documents involves a tiny amount of analysis being done each time a new object (title, paragraph, image, etc.) is entered, whereas with SGML most of that analysis is loaded to the front of the project. The authors need to be given an opportunity to express their collective views and those views need to be reflected in the structure. While authoring documents, the authors should rely on the agreements reached during the analysis stage - the structure allows them to do so. If they find it to be deficient, they should say so, but eventually they should all be satisfied that they have something workable, even if they didn't back all of the decisions 100%. If you find that authoring to a structure is a substantial overhead, you should examine the structure. It's possible that you could benefit from the creation of a structure aimed at making authoring simpler and that a post-process could convert the data to the destination format. Issues such as augmenting documents with database information and otherwise dynamically rendered documents will likely mean that an author having a view of the data only vaguely resembles what the the user sees will become much more common in the future. I believe that this also has the potential to become a problem for technical writers, but that's another topic... -- Regards, Marcus Carr email: firstname.lastname@example.org ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein ** To unsubscribe, send a message to email@example.com ** ** with "unsubscribe framers" (no quotes) in the body. **