XML and FrameMaker
Thank you very much to you for your response. I can see I misunderstood some point on this topic, but some doubts still remains in the roundtrip process. In any case I didn?t mean that working with a ?tag-based? editor + ?style-sheets? is better than working with FM (from the authoring point of view), but I need to demonstrate that to people (and to me) for convincing them to invest time and money on it. I?ve read the Adobe documentation on this topic and the XMLCookBook tutorial, but (I think) this is too short and simple for the importance and complexity of the matter. In order not to pester you with too many questions, I would appreciate some information source for a deeper understanding of the way of dealing with XML in FM. In addition to this, I?d like to pose you some more questions: 1) What is the relationship between DTD and EDD in an structure application: I though DTD would direct structure editing (element catalogue, structure editor, ) and EDD would maintain the mapping between structure and presentation, BUT it seems it is not the case, at least not for XDocBook. In XDocBook application FM DocBook structure is not DocBook compliant (for example: FM ?Chapter? is DocBook ?chapter?. Also, the FM ?Head? element is not a DocBook Element): That?s the reason why we need Read/Write rules. No need for if FM would use the DTD directly. NOTE: I?m not telling the R/W Rules mechanism is not an important one. I see it is needed if FM is using a kind of internal structure definition and I?d like to export that structure to be compliant with and external application DTD. On the other hand, for modifying structures on Import/Export I would not have re-invented the wheel, XSLT (or DSSL for SGML) could do the job much better. On the other hand, where is the whole set of ?Document Definition? rules for a document type? I couldn?t find an EDD containing the whole DocBook grammar. 2) Is really EDD (internally) supporting the document structure (Schema) information? If that were the case, having EDD store structure and presentation information is not a good practice. I would expect to have a ?Structure-Definition? document spitted form a ?Presentation-Definition? document. I think we should agree in this point (??). I would fear to touch my precious ?Document Type Definition? documentation just to note down that some font has to change (today) and some other feature tomorrow Then, this decoupling is compulsory (I think). 3) Another set of doubts is (stemming from the previous troubles) the appropriate strategy for designing my own XML application in FM. For example, is trying to make profit of some already designed structured application and like to ?Re-vamp? some structured template: How can I do that? How can I get the ?grammar? for that structured document and the presentation mapping for that grammar? Well, I seems like I?m at loss on this field, and, as stated before, I wouldn?t like to bore you with many (and maybe na?ve) questions. And I would appreciate answers as I do references to interesting sources of information. Regards, Pedro
XML and FrameMaker
There is a manual in PDF format titled "Structure Application Developer's Guide" where you may find answers some of your questions. Nothing beats experience but understanding that manual is a good starting point. As you can see from the Structured Application Definition Document XDocBook is identified as: DTD Template Read/write rules CSS2 Preferences Generate CSS2 Add Fm CSS Attribute to XML XML Stylesheet Type URI Use API client Namespace Doctype Entity locations All of these things are used when loading or unloading an XDocBook instance with Framemaker. Notice that nowhere is an EDD specified. -Original Message- From: framers-bounces+richard.allen=uspto.gov at lists.frameusers.com [mailto:framers-bounces+richard.allen=uspto@lists.frameusers.com] On Behalf Of Pedro Pastor Sent: Wednesday, January 17, 2007 5:44 AM To: framers at FrameUsers.com Subject: XML and FrameMaker Thank you very much to you for your response. I can see I misunderstood some point on this topic, but some doubts still remains in the roundtrip process. In any case I didn't mean that working with a "tag-based" editor + "style-sheets" is better than working with FM (from the authoring point of view), but I need to demonstrate that to people (and to me) for convincing them to invest time and money on it. I've read the Adobe documentation on this topic and the XMLCookBook tutorial, but (I think) this is too short and simple for the importance and complexity of the matter. In order not to pester you with too many questions, I would appreciate some information source for a deeper understanding of the way of dealing with XML in FM. In addition to this, I'd like to pose you some more questions: 1) What is the relationship between DTD and EDD in an structure application: I though DTD would direct structure editing (element catalogue, structure editor, ...) and EDD would maintain the mapping between structure and presentation, BUT it seems it is not the case, at least not for XDocBook. In XDocBook application FM DocBook structure is not DocBook compliant (for example: FM "Chapter" is DocBook "chapter". Also, the FM "Head" element is not a DocBook Element): That's the reason why we need Read/Write rules. No need for if FM would use the DTD directly. NOTE: I'm not telling the R/W Rules mechanism is not an important one. I see it is needed if FM is using a kind of internal structure definition and I'd like to export that structure to be compliant with and external application DTD. On the other hand, for modifying structures on Import/Export I would not have re-invented the wheel, XSLT (or DSSL for SGML) could do the job much better. On the other hand, where is the whole set of "Document Definition" rules for a document type? I couldn't find an EDD containing the whole DocBook grammar. 2) Is really EDD (internally) supporting the document structure (Schema) information? If that were the case, having EDD store structure and presentation information is not a good practice. I would expect to have a "Structure-Definition" document spitted form a "Presentation-Definition" document. I think we should agree in this point (??). I would fear to touch my precious "Document Type Definition" documentation just to note down that some font has to change (today) and some other feature tomorrow Then, this decoupling is compulsory (I think). 3) Another set of doubts is (stemming from the previous troubles) the appropriate strategy for designing my own XML application in FM. For example, is trying to make profit of some already designed structured application and like to "Re-vamp" some structured template: How can I do that? How can I get the "grammar" for that structured document and the presentation mapping for that grammar? Well, I seems like I'm at loss on this field, and, as stated before, I wouldn't like to bore you with many (and maybe na?ve) questions. And I would appreciate answers as I do references to interesting sources of information. Regards, Pedro ___ You are currently subscribed to Framers as Richard.Allen at uspto.gov. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/richard.allen%40uspto.gov Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
XML and FrameMaker
Pedro, In general, the EDD contains both the document definition AND its relationship to the formatting. I do not see this as being a problem as you suggest it is and have been happily developing EDDs for over 10 years. To create an EDD, the DTD is imported into FrameMaker. The read/write rules will be used to rename or drop elements as required. If you need to update your DTD, you can then re-import into the existing EDD. There are two main ways in which formatting can be added to an EDD; either by putting the formatting directly into the EDD; or by referencing styles in the template. A combination of both is most likely to be used in order to fully benefit from the EDD's context rules. Using the template approach would allow you to separate most formatting from the EDD ... the template therefore being your stylesheet. You would then be able to change your template with a need to edit the EDD each time. As Allen points out, this is all documented in the Developer's Guide and will answer your questions in a lot more detail. Regards Mark Poston Mekon Ltd. -Original Message- From: framers-bounces+mark.poston=mekon.com at lists.frameusers.com [mailto:framers-bounces+mark.poston=mekon@lists.frameusers.com] On Behalf Of Pedro Pastor Sent: 17 January 2007 10:44 To: framers at FrameUsers.com Subject: XML and FrameMaker Thank you very much to you for your response. I can see I misunderstood some point on this topic, but some doubts still remains in the roundtrip process. In any case I didn't mean that working with a "tag-based" editor + "style-sheets" is better than working with FM (from the authoring point of view), but I need to demonstrate that to people (and to me) for convincing them to invest time and money on it. I've read the Adobe documentation on this topic and the XMLCookBook tutorial, but (I think) this is too short and simple for the importance and complexity of the matter. In order not to pester you with too many questions, I would appreciate some information source for a deeper understanding of the way of dealing with XML in FM. In addition to this, I'd like to pose you some more questions: 1) What is the relationship between DTD and EDD in an structure application: I though DTD would direct structure editing (element catalogue, structure editor, ...) and EDD would maintain the mapping between structure and presentation, BUT it seems it is not the case, at least not for XDocBook. In XDocBook application FM DocBook structure is not DocBook compliant (for example: FM "Chapter" is DocBook "chapter". Also, the FM "Head" element is not a DocBook Element): That's the reason why we need Read/Write rules. No need for if FM would use the DTD directly. NOTE: I'm not telling the R/W Rules mechanism is not an important one. I see it is needed if FM is using a kind of internal structure definition and I'd like to export that structure to be compliant with and external application DTD. On the other hand, for modifying structures on Import/Export I would not have re-invented the wheel, XSLT (or DSSL for SGML) could do the job much better. On the other hand, where is the whole set of "Document Definition" rules for a document type? I couldn't find an EDD containing the whole DocBook grammar. 2) Is really EDD (internally) supporting the document structure (Schema) information? If that were the case, having EDD store structure and presentation information is not a good practice. I would expect to have a "Structure-Definition" document spitted form a "Presentation-Definition" document. I think we should agree in this point (??). I would fear to touch my precious "Document Type Definition" documentation just to note down that some font has to change (today) and some other feature tomorrow Then, this decoupling is compulsory (I think). 3) Another set of doubts is (stemming from the previous troubles) the appropriate strategy for designing my own XML application in FM. For example, is trying to make profit of some already designed structured application and like to "Re-vamp" some structured template: How can I do that? How can I get the "grammar" for that structured document and the presentation mapping for that grammar? Well, I seems like I'm at loss on this field, and, as stated before, I wouldn't like to bore you with many (and maybe na?ve) questions. And I would appreciate answers as I do references to interesting sources of information. Regards, Pedro ___ You are currently subscribed to Framers as mark.poston at mekon.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/mark.poston%40mekon.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
XML and FrameMaker
I recommend that you check the original, and downloadable DTDs for Docbook. http://www.docbook.org/ They also have a Simplified Docbook which might help you also. There are at least two books that I'm aware of that give an explanation of the Docbook DTD. Go to the above site and check them out. Scott
XML and FrameMaker
Hi Scott, Thanks for the info, but DocBook is not the problem here. I have some good command of the XML DocBook DTD (from version 3). I have also developed simplified version for DocBook for organization specific needs (just to realize myself that there is nothing better than using the original). To my understanding, the key point in this discussion is that FrameMaker is not a "native" SGML/XML tool. It has its own way of dealing with structured documents. In some way, it has reinvented the wheel (being SGML much older than FM, and with many SGML processing tools available out there). I could be wrong, but I could find at least some other people that are thinking (more o less) the same way: http://www.getnet.net/~swhitlat/DocBook/Frame_Project_Readme.php
XML and FrameMaker
FM is primarily a presentation tool. It formats and produces a media specific output. Something like Epic Editor is primarily an SGML tool that ignores media specific output. The structure is all that is of importance. The short answer to your question is yes. You don't need a template (stylesheet) EDD, or the like as long as you specify a valid DTD for the document. It will look like you don't know anything about formatting, but if that is ok with you, then you have the means to change that at a later date, since you will have your content tagged, structured, and validated. Scott At 7:46 PM +0100 1/17/07, Pedro Pastor wrote: > >Finally, as very simple example of what I'm saying: > >Could I just specify a DTD to FM without any Template, EDD, MML or other >associate file and just begin typing a new valid and "plain" structured >text, even if the "look&feel" is very basic (even if it is tag based)? > >Regards, > >Pedro >
XML and FrameMaker
The argument as to whether FM is a native XML editor has been running for years. It's true that FrameMaker supports XML/SGML in a different way to other tools but at the end of the day what does it do? It allows users to open an XML/SGML instance, edit it, validate it within the editor, and then save it directly back out as XML/SGML ... fully valid against the DTD or Schema. On this basis I consider FrameMaker to be a native XML and SGML editor that competes at the same level as all other XML authoring tools. To make any XML authoring tool viable for users to work with, they all need some degree of customisation. All need stylesheets ... Epic uses FOSI, XMetaL uses CSS, FrameMaker uses EDDs. All need some way to map elements to object types (e.g. graphics, tables, cross references etc.). The work required to implement a solution in FrameMaker is comparable to other author tools. In fact, I find working with an EDD much easier, quicker and more logical than other products. The fact that FrameMaker is itself a high quality pagination tools means that users do not need to employ or invest in external processes to create their printed material. If different templates are required it is very easy for a FrameMaker user (without EDD training in many cases) to create them. FM will not allow you to simply open up an XML instance and start editing. Many other authoring tools also need some level of doctype configuration to do this. I would never recommend this for any of my client though. If this is what you need then a dedicated XML authoring tool is perhaps the wrong tool. Using Oxygen, XMLSpy, Stylus Studio would be more suitable ... I do not consider these to be authoring tools though. One of the most important factors is what the authoring experience is like. Whilst there are many authors who will be happy working with XML tags there are just as many, if not more, who will not be. FrameMaker provides a very intuitive user interface that makes the creation of structured documents very easy. I have yet to find another authoring tool with a structure view as powerful as FrameMaker's. Another factor is whether you are an existing FrameMaker user who wants to move to authoring XML content. With FrameMaker being able to support structure out of the box, the argument to move away from using it must be justified. This is a much harder proposition as the total investment will be higher (e.g. software licenses (authoring tool, pagination engine), user training, customisation etc.). Adobe's continued commitment to FrameMaker and improved XML support will ensure that it will remain one of the best tools for authoring XML content. Regards Mark Poston -Original Message- From: framers-bounces+mark.poston=mekon.com at lists.frameusers.com [mailto:framers-bounces+mark.poston=mekon@lists.frameusers.com] On Behalf Of Pedro Pastor Sent: 17 January 2007 18:46 To: framers at FrameUsers.com Subject: RE: XML and FrameMaker Hi Scott, Thanks for the info, but DocBook is not the problem here. I have some good command of the XML DocBook DTD (from version 3). I have also developed simplified version for DocBook for organization specific needs (just to realize myself that there is nothing better than using the original). To my understanding, the key point in this discussion is that FrameMaker is not a "native" SGML/XML tool. It has its own way of dealing with structured documents. In some way, it has reinvented the wheel (being SGML much older than FM, and with many SGML processing tools available out there). I could be wrong, but I could find at least some other people that are thinking (more o less) the same way: http://www.getnet.net/~swhitlat/DocBook/Frame_Project_Readme.php
XML and FrameMaker
Thank you very much to you for your response. I can see I misunderstood some point on this topic, but some doubts still remains in the roundtrip process. In any case I didnt mean that working with a tag-based editor + style-sheets is better than working with FM (from the authoring point of view), but I need to demonstrate that to people (and to me) for convincing them to invest time and money on it. Ive read the Adobe documentation on this topic and the XMLCookBook tutorial, but (I think) this is too short and simple for the importance and complexity of the matter. In order not to pester you with too many questions, I would appreciate some information source for a deeper understanding of the way of dealing with XML in FM. In addition to this, Id like to pose you some more questions: 1) What is the relationship between DTD and EDD in an structure application: I though DTD would direct structure editing (element catalogue, structure editor, ) and EDD would maintain the mapping between structure and presentation, BUT it seems it is not the case, at least not for XDocBook. In XDocBook application FM DocBook structure is not DocBook compliant (for example: FM Chapter is DocBook chapter. Also, the FM Head element is not a DocBook Element): Thats the reason why we need Read/Write rules. No need for if FM would use the DTD directly. NOTE: Im not telling the R/W Rules mechanism is not an important one. I see it is needed if FM is using a kind of internal structure definition and Id like to export that structure to be compliant with and external application DTD. On the other hand, for modifying structures on Import/Export I would not have re-invented the wheel, XSLT (or DSSL for SGML) could do the job much better. On the other hand, where is the whole set of Document Definition rules for a document type? I couldnt find an EDD containing the whole DocBook grammar. 2) Is really EDD (internally) supporting the document structure (Schema) information? If that were the case, having EDD store structure and presentation information is not a good practice. I would expect to have a Structure-Definition document spitted form a Presentation-Definition document. I think we should agree in this point (¿?). I would fear to touch my precious Document Type Definition documentation just to note down that some font has to change (today) and some other feature tomorrow Then, this decoupling is compulsory (I think). 3) Another set of doubts is (stemming from the previous troubles) the appropriate strategy for designing my own XML application in FM. For example, is trying to make profit of some already designed structured application and like to Re-vamp some structured template: How can I do that? How can I get the grammar for that structured document and the presentation mapping for that grammar? Well, I seems like Im at loss on this field, and, as stated before, I wouldnt like to bore you with many (and maybe naïve) questions. And I would appreciate answers as I do references to interesting sources of information. Regards, Pedro ___ 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: XML and FrameMaker
There is a manual in PDF format titled "Structure Application Developer's Guide" where you may find answers some of your questions. Nothing beats experience but understanding that manual is a good starting point. As you can see from the Structured Application Definition Document XDocBook is identified as: DTD Template Read/write rules CSS2 Preferences Generate CSS2 Add Fm CSS Attribute to XML XML Stylesheet Type URI Use API client Namespace Doctype Entity locations All of these things are used when loading or unloading an XDocBook instance with Framemaker. Notice that nowhere is an EDD specified. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Pastor Sent: Wednesday, January 17, 2007 5:44 AM To: framers@FrameUsers.com Subject: XML and FrameMaker Thank you very much to you for your response. I can see I misunderstood some point on this topic, but some doubts still remains in the roundtrip process. In any case I didn't mean that working with a "tag-based" editor + "style-sheets" is better than working with FM (from the authoring point of view), but I need to demonstrate that to people (and to me) for convincing them to invest time and money on it. I've read the Adobe documentation on this topic and the XMLCookBook tutorial, but (I think) this is too short and simple for the importance and complexity of the matter. In order not to pester you with too many questions, I would appreciate some information source for a deeper understanding of the way of dealing with XML in FM. In addition to this, I'd like to pose you some more questions: 1) What is the relationship between DTD and EDD in an structure application: I though DTD would direct structure editing (element catalogue, structure editor, ...) and EDD would maintain the mapping between structure and presentation, BUT it seems it is not the case, at least not for XDocBook. In XDocBook application FM DocBook structure is not DocBook compliant (for example: FM "Chapter" is DocBook "chapter". Also, the FM "Head" element is not a DocBook Element): That's the reason why we need Read/Write rules. No need for if FM would use the DTD directly. NOTE: I'm not telling the R/W Rules mechanism is not an important one. I see it is needed if FM is using a kind of internal structure definition and I'd like to export that structure to be compliant with and external application DTD. On the other hand, for modifying structures on Import/Export I would not have re-invented the wheel, XSLT (or DSSL for SGML) could do the job much better. On the other hand, where is the whole set of "Document Definition" rules for a document type? I couldn't find an EDD containing the whole DocBook grammar. 2) Is really EDD (internally) supporting the document structure (Schema) information? If that were the case, having EDD store structure and presentation information is not a good practice. I would expect to have a "Structure-Definition" document spitted form a "Presentation-Definition" document. I think we should agree in this point (¿?). I would fear to touch my precious "Document Type Definition" documentation just to note down that some font has to change (today) and some other feature tomorrow Then, this decoupling is compulsory (I think). 3) Another set of doubts is (stemming from the previous troubles) the appropriate strategy for designing my own XML application in FM. For example, is trying to make profit of some already designed structured application and like to "Re-vamp" some structured template: How can I do that? How can I get the "grammar" for that structured document and the presentation mapping for that grammar? Well, I seems like I'm at loss on this field, and, as stated before, I wouldn't like to bore you with many (and maybe naïve) questions. And I would appreciate answers as I do references to interesting sources of information. Regards, Pedro ___ 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/richard.allen%40uspto.gov Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ 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: XML and FrameMaker
Pedro, In general, the EDD contains both the document definition AND its relationship to the formatting. I do not see this as being a problem as you suggest it is and have been happily developing EDDs for over 10 years. To create an EDD, the DTD is imported into FrameMaker. The read/write rules will be used to rename or drop elements as required. If you need to update your DTD, you can then re-import into the existing EDD. There are two main ways in which formatting can be added to an EDD; either by putting the formatting directly into the EDD; or by referencing styles in the template. A combination of both is most likely to be used in order to fully benefit from the EDD's context rules. Using the template approach would allow you to separate most formatting from the EDD ... the template therefore being your stylesheet. You would then be able to change your template with a need to edit the EDD each time. As Allen points out, this is all documented in the Developer's Guide and will answer your questions in a lot more detail. Regards Mark Poston Mekon Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Pastor Sent: 17 January 2007 10:44 To: framers@FrameUsers.com Subject: XML and FrameMaker Thank you very much to you for your response. I can see I misunderstood some point on this topic, but some doubts still remains in the roundtrip process. In any case I didn't mean that working with a "tag-based" editor + "style-sheets" is better than working with FM (from the authoring point of view), but I need to demonstrate that to people (and to me) for convincing them to invest time and money on it. I've read the Adobe documentation on this topic and the XMLCookBook tutorial, but (I think) this is too short and simple for the importance and complexity of the matter. In order not to pester you with too many questions, I would appreciate some information source for a deeper understanding of the way of dealing with XML in FM. In addition to this, I'd like to pose you some more questions: 1) What is the relationship between DTD and EDD in an structure application: I though DTD would direct structure editing (element catalogue, structure editor, ...) and EDD would maintain the mapping between structure and presentation, BUT it seems it is not the case, at least not for XDocBook. In XDocBook application FM DocBook structure is not DocBook compliant (for example: FM "Chapter" is DocBook "chapter". Also, the FM "Head" element is not a DocBook Element): That's the reason why we need Read/Write rules. No need for if FM would use the DTD directly. NOTE: I'm not telling the R/W Rules mechanism is not an important one. I see it is needed if FM is using a kind of internal structure definition and I'd like to export that structure to be compliant with and external application DTD. On the other hand, for modifying structures on Import/Export I would not have re-invented the wheel, XSLT (or DSSL for SGML) could do the job much better. On the other hand, where is the whole set of "Document Definition" rules for a document type? I couldn't find an EDD containing the whole DocBook grammar. 2) Is really EDD (internally) supporting the document structure (Schema) information? If that were the case, having EDD store structure and presentation information is not a good practice. I would expect to have a "Structure-Definition" document spitted form a "Presentation-Definition" document. I think we should agree in this point (¿?). I would fear to touch my precious "Document Type Definition" documentation just to note down that some font has to change (today) and some other feature tomorrow Then, this decoupling is compulsory (I think). 3) Another set of doubts is (stemming from the previous troubles) the appropriate strategy for designing my own XML application in FM. For example, is trying to make profit of some already designed structured application and like to "Re-vamp" some structured template: How can I do that? How can I get the "grammar" for that structured document and the presentation mapping for that grammar? Well, I seems like I'm at loss on this field, and, as stated before, I wouldn't like to bore you with many (and maybe naïve) questions. And I would appreciate answers as I do references to interesting sources of information. Regards, Pedro ___ 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/mark.poston%40mekon.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources an
Re: XML and FrameMaker
I recommend that you check the original, and downloadable DTDs for Docbook. http://www.docbook.org/ They also have a Simplified Docbook which might help you also. There are at least two books that I'm aware of that give an explanation of the Docbook DTD. Go to the above site and check them out. Scott ___ 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: XML and FrameMaker
Hi Scott, Thanks for the info, but DocBook is not the problem here. I have some good command of the XML DocBook DTD (from version 3). I have also developed simplified version for DocBook for organization specific needs (just to realize myself that there is nothing better than using the original). To my understanding, the key point in this discussion is that FrameMaker is not a "native" SGML/XML tool. It has its own way of dealing with structured documents. In some way, it has reinvented the wheel (being SGML much older than FM, and with many SGML processing tools available out there). I could be wrong, but I could find at least some other people that are thinking (more o less) the same way: http://www.getnet.net/~swhitlat/DocBook/Frame_Project_Readme.php >From /SGML users point of view, it would've been easier to have FM work internally with DTD's. The second part of the round trip, presentations design and structure mapping, seems very powerful in FM. Finally, as very simple example of what I'm saying: Could I just specify a DTD to FM without any Template, EDD, MML or other associate file and just begin typing a new valid and "plain" structured text, even if the "look&feel" is very basic (even if it is tag based)? Regards, Pedro -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de [EMAIL PROTECTED] Enviado el: miércoles, 17 de enero de 2007 18:09 Para: Pedro Pastor; framers@FrameUsers.com Asunto: Re: XML and FrameMaker I recommend that you check the original, and downloadable DTDs for Docbook. http://www.docbook.org/ They also have a Simplified Docbook which might help you also. There are at least two books that I'm aware of that give an explanation of the Docbook DTD. Go to the above site and check them out. Scott ___ 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/pps%40dlsi.ua.es Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info. ___ 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: XML and FrameMaker
FM is primarily a presentation tool. It formats and produces a media specific output. Something like Epic Editor is primarily an SGML tool that ignores media specific output. The structure is all that is of importance. The short answer to your question is yes. You don't need a template (stylesheet) EDD, or the like as long as you specify a valid DTD for the document. It will look like you don't know anything about formatting, but if that is ok with you, then you have the means to change that at a later date, since you will have your content tagged, structured, and validated. Scott At 7:46 PM +0100 1/17/07, Pedro Pastor wrote: Finally, as very simple example of what I'm saying: Could I just specify a DTD to FM without any Template, EDD, MML or other associate file and just begin typing a new valid and "plain" structured text, even if the "look&feel" is very basic (even if it is tag based)? Regards, Pedro ___ 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: XML and FrameMaker
The argument as to whether FM is a native XML editor has been running for years. It's true that FrameMaker supports XML/SGML in a different way to other tools but at the end of the day what does it do? It allows users to open an XML/SGML instance, edit it, validate it within the editor, and then save it directly back out as XML/SGML ... fully valid against the DTD or Schema. On this basis I consider FrameMaker to be a native XML and SGML editor that competes at the same level as all other XML authoring tools. To make any XML authoring tool viable for users to work with, they all need some degree of customisation. All need stylesheets ... Epic uses FOSI, XMetaL uses CSS, FrameMaker uses EDDs. All need some way to map elements to object types (e.g. graphics, tables, cross references etc.). The work required to implement a solution in FrameMaker is comparable to other author tools. In fact, I find working with an EDD much easier, quicker and more logical than other products. The fact that FrameMaker is itself a high quality pagination tools means that users do not need to employ or invest in external processes to create their printed material. If different templates are required it is very easy for a FrameMaker user (without EDD training in many cases) to create them. FM will not allow you to simply open up an XML instance and start editing. Many other authoring tools also need some level of doctype configuration to do this. I would never recommend this for any of my client though. If this is what you need then a dedicated XML authoring tool is perhaps the wrong tool. Using Oxygen, XMLSpy, Stylus Studio would be more suitable ... I do not consider these to be authoring tools though. One of the most important factors is what the authoring experience is like. Whilst there are many authors who will be happy working with XML tags there are just as many, if not more, who will not be. FrameMaker provides a very intuitive user interface that makes the creation of structured documents very easy. I have yet to find another authoring tool with a structure view as powerful as FrameMaker's. Another factor is whether you are an existing FrameMaker user who wants to move to authoring XML content. With FrameMaker being able to support structure out of the box, the argument to move away from using it must be justified. This is a much harder proposition as the total investment will be higher (e.g. software licenses (authoring tool, pagination engine), user training, customisation etc.). Adobe's continued commitment to FrameMaker and improved XML support will ensure that it will remain one of the best tools for authoring XML content. Regards Mark Poston -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Pastor Sent: 17 January 2007 18:46 To: framers@FrameUsers.com Subject: RE: XML and FrameMaker Hi Scott, Thanks for the info, but DocBook is not the problem here. I have some good command of the XML DocBook DTD (from version 3). I have also developed simplified version for DocBook for organization specific needs (just to realize myself that there is nothing better than using the original). To my understanding, the key point in this discussion is that FrameMaker is not a "native" SGML/XML tool. It has its own way of dealing with structured documents. In some way, it has reinvented the wheel (being SGML much older than FM, and with many SGML processing tools available out there). I could be wrong, but I could find at least some other people that are thinking (more o less) the same way: http://www.getnet.net/~swhitlat/DocBook/Frame_Project_Readme.php >From /SGML users point of view, it would've been easier to have FM work internally with DTD's. The second part of the round trip, presentations design and structure mapping, seems very powerful in FM. Finally, as very simple example of what I'm saying: Could I just specify a DTD to FM without any Template, EDD, MML or other associate file and just begin typing a new valid and "plain" structured text, even if the "look&feel" is very basic (even if it is tag based)? Regards, Pedro -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de [EMAIL PROTECTED] Enviado el: miércoles, 17 de enero de 2007 18:09 Para: Pedro Pastor; framers@FrameUsers.com Asunto: Re: XML and FrameMaker I recommend that you check the original, and downloadable DTDs for Docbook. http://www.docbook.org/ They also have a Simplified Docbook which might help you also. There are at least two books that I'm aware of that give an explanation of the Docbook DTD. Go to the above site and check them out. Scott ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PRO
