Re: New to the list, and asking for help
At 16:37 +0100 16/1/07, Pedro Pastor wrote: 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!! 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. Pedro... Daniel, Scott and Matt have already given you great answers to your interesting, and understandable, questions. All I'd wish to add is to suggest that, if your are planning to create your own EDD, you initially try using text formatting rules that refer out of the EDD to the FrameMaker's document's tags for formatting? This is by no means the only way to do it, but it follows the principle that software engineers call 'separation of concerns': each 'thing' should have only one task. Here, the EDD controls the structure, and the FrameMaker document controls the presentation. Swap the template, and you can completely transform a document without any change to the EDD. Don't be misled by the fact that you can import tag definitions into, and out of, an EDD. This is merely a side-effect of an EDD being a structured FrameMaker document. This is just one way of storing tag definitions, and probably not a good one other than for simple documents. Equally, do not be misled by the fact that a non-EDD FrameMaker document can be used to store and propagate structural information: again, this is almost certainly not a good way to achieve this... keep it in the EDD, and import from there. So, for 'weird and complicated', instead read 'powerful and flexible' ;-) -- Steve ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
New to the list, and asking for help
At 16:37 +0100 16/1/07, Pedro Pastor wrote: >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!! > >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. Pedro... Daniel, Scott and Matt have already given you great answers to your interesting, and understandable, questions. All I'd wish to add is to suggest that, if your are planning to create your own EDD, you initially try using text formatting rules that refer out of the EDD to the FrameMaker's document's tags for formatting? This is by no means the only way to do it, but it follows the principle that software engineers call 'separation of concerns': each 'thing' should have only one task. Here, the EDD controls the structure, and the FrameMaker document controls the presentation. Swap the template, and you can completely transform a document without any change to the EDD. Don't be misled by the fact that you can import tag definitions into, and out of, an EDD. This is merely a side-effect of an EDD being a structured FrameMaker document. This is just one way of storing tag definitions, and probably not a good one other than for simple documents. Equally, do not be misled by the fact that a non-EDD FrameMaker document can be used to store and propagate structural information: again, this is almost certainly not a good way to achieve this... keep it in the EDD, and import from there. So, for 'weird and complicated', instead read 'powerful and flexible' ;-) -- Steve
Re: New to the list, and asking for help
Pedro, Using a pure editor to tag your document with XML tags is fine. It won't print anything but text, including the structure tags for all to see. The EDD is the translation document that assigns the format tags to the structure tags. The FrameMaker template contains the formatting instructions for the output. The rules provide instructions for converting to formatting. The structure document is pure text, and only text. It contains no presentation information like formatting. The EDD and template provide the formatting information for presentation. Do not fall into the fallacy that a XSLT or CSS will provide a formatted document that you can print from. XSLT can transform it but it takes a great deal of work to get one to output printed format. CSS is only for web presentation. Even using things like Epic Editor, you still have to have the DTD and a separate style document to produce a format for presentation. FrameMaker provides both aspects in one package. Scott At 4:37 PM +0100 1/16/07, Pedro Pastor wrote: I am new to this list. I was lurking for a while and I finally decided to show up. My main interest in FrameMaker is for XML-documents authoring tasks. I am quite new to FrameMaker (few weeks experience, 7.2 installed), but I have a good background and experience working with XML technologies. The first impression when learning Structured FM is double: - An impressive tool. - Weird and complicated way of dealing with XML. 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 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!! 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. 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!!). 4) When working with XML applications like DocBook, I don't understand the need for Rules just to change capital letters. It seems like FM is not working internally in XDocBook when you choose to work with an XDocBook application. In fact, the structure generated by FM is not even DocBook 4.x compliant. 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. Thank you very much. Pedro Pastor Software Engineering Department. University of Alicante Spain ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Re: New to the list, and asking for help
--- Pedro Pastor [EMAIL PROTECTED] 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 Frames 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.
New to the list, and asking for help
I am new to this list. I was lurking for a while and I finally decided to show up. My main interest in FrameMaker is for XML-documents authoring tasks. I am quite new to FrameMaker (few weeks experience, 7.2 installed), but I have a good background and experience working with XML technologies. The first impression when learning Structured FM is double: - An impressive tool. - Weird and complicated way of dealing with XML. 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 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!! 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. 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!!). 4) When working with XML applications like DocBook, I don't understand the need for "Rules" just to change capital letters. It seems like FM is not working internally in XDocBook when you choose to work with an XDocBook application. In fact, the structure generated by FM is not even DocBook 4.x compliant. 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. Thank you very much. Pedro Pastor Software Engineering Department. University of Alicante Spain
New to the list, and asking for help
Pedro, Using a pure editor to tag your document with XML tags is fine. It won't print anything but text, including the structure tags for all to see. The EDD is the translation document that assigns the format tags to the structure tags. The FrameMaker template contains the formatting instructions for the output. The rules provide instructions for converting to formatting. The structure document is pure text, and only text. It contains no presentation information like formatting. The EDD and template provide the formatting information for presentation. Do not fall into the fallacy that a XSLT or CSS will provide a formatted document that you can print from. XSLT can transform it but it takes a great deal of work to get one to output printed format. CSS is only for web presentation. Even using things like Epic Editor, you still have to have the DTD and a separate style document to produce a format for presentation. FrameMaker provides both aspects in one package. Scott At 4:37 PM +0100 1/16/07, Pedro Pastor wrote: >I am new to this list. I was lurking for a while and I finally decided >to show up. > >My main interest in FrameMaker is for XML-documents authoring tasks. I >am quite new to FrameMaker (few weeks experience, 7.2 installed), but I >have a good background and experience working with XML technologies. > >The first impression when learning Structured FM is double: > >- An impressive tool. >- Weird and complicated way of dealing with XML. > >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 > >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!! > >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. > >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!!). > >4) When working with XML applications like DocBook, I don't >understand the need for "Rules" just to change capital letters. It seems >like FM is not working internally in XDocBook when you choose to work >with an XDocBook application. In fact, the structure generated by FM is >not even DocBook 4.x compliant. > > > 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. > >Thank you very much. > >Pedro Pastor >Software Engineering Department. >University of Alicante >Spain
New to the list, and asking for help
Hi Pedro, see responses below -Matt Sullivan GRAFIX Training, Inc. An Adobe Authorized Training Center www.grafixtraining.com 888 882-2819 -Original Message- From: framers-bounces+matt=grafixtraining@lists.frameusers.com [mailto:framers-bounces+matt=grafixtraining.com at lists.frameusers.com] On Behalf Of Pedro Pastor My main interest in FrameMaker is for XML-documents authoring tasks. I am quite new to FrameMaker (few weeks experience, 7.2 installed), but I have a good background and experience working with XML technologies. The first impression when learning Structured FM is double: - An impressive tool. - Weird and complicated way of dealing with XML. 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 ***Some folks need to both send and receive XML. Made-up example: Boeing gets XML from subcontractors, but must combine and deliver as XML to American Airlines. Some folks need only format XML for output, take your pick. I just finished a phone directory project for CSULB that went quite smoothly in InDesign, didn't require a DTD or really any structure experience at all. Some folks need only to deliver XML versions of their doc's. If so, unstructured Frame might fit the bill, without the rigors of a Structured Application. You lose a lot of control, but it gets the job done. 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!! ***OK...but that presentation info is for FrameMaker for a given authoring environment. That's a bit like saying CSS goes against those principles by formatting the content in a browser window. The EDD allows for consistent formatting in a given environment. That formatting info is not forced into the XML/SGML unless passed as attributes and values. 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. *** Think of the Template as storing the Unstructured Frame items (see the File/Import/Formats dialog box) and the EDD as storing text format rules. A template has a copy of the EDD stored with it, as does any structured Frame doc. Within documents, Frame does not allow reference to an external EDD nor does it allow reference to an external template. I typically keep the EDD separate, but import any changes to the EDD immediately to my template. 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!!). ***See response to 2) 4) When working with XML applications like DocBook, I don't understand the need for "Rules" just to change capital letters. It seems like FM is not working internally in XDocBook when you choose to work with an XDocBook application. In fact, the structure generated by FM is not even DocBook 4.x compliant. ***Reference Concrete Syntax and the SGML/XML declaration establishes naming limitations for structured element names. Frame allows deviation from those limits through the Read/Write Rules. These rules also allow for various element and attribute changes, as well as changing attribute values into actual Frame formatting, and changing Frame formatting back into attribute values. 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. ***Depends on what your definition of "is" is (Sorry, Bill Clinton) By Authoring XML, if you mean writing and editing long documents (with graphics, numbering, references, and the like) to be delivered in XML, print, PDF, and other formats, I don't know of a better tool. Seriously, if anyone does, please let me know...I'll put my eggs in that basket. Frame is not the world's most intuitive or up-to-date interface, but to me is the Toyota Land Cruiser (or Range Rover, if you prefer) of documentation.
New to the list, and asking for help
--- Pedro Pastor 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.
