<div><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left">Hi all,</span></div><div><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left"><br>
</span></div><div><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left">I replied to the adobe forum post soliciting feedback for feature requests. I got some push back on this. So I am curious what other people think of the following idea. Am I all wet or is this just far less important than I think? </span></div>
<span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left"><div><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left"><br>
</span></div>FrameMaker should be converted into a true XML authoring environment. There should be no structured or unstructured frameamerk. There should just be FrameMaker, which has XML files. When I upgrade to the latest version of FrameMaker, all my binary files should be converted into XML documents. You should publish a XSD that defines the XML doc structure and leverage the existing XSLT engine, so that out of the box any FrameMaker book can be converted into any publishing format the user would care to. And also allow the user to design their own XSLTS to convert into some other format that people haven't even thought of yet. That way I can truly single source all my content in FrameMaker instead of having to use the buggy Framemaker to Robohelp integration.</span><div>
<div style="text-align:left"><font color="#333333" face="AdobeCleanRegular, Helvetica Neue, Arial, sans-serif"><span style="font-size:14px;line-height:21px"><br></span></font></div><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left">In addition, provide a GUI that allows me to design a template and structure (similar to structured framemaker ) that allows me to perform schema validation of the structure and enforces controls on what the template may contain. Basically, this would just be a port of EDD more or less.</span></div>
<div><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left"><br></span></div><div><span style="text-align:left;font-size:14px;line-height:21px"><font color="#333333" face="AdobeCleanRegular, Helvetica Neue, Arial, sans-serif">the point is that FrameMaker fundamentally needs to be an XML authoring environment instead of XML authoring kinda sorta supported if you are willing to bite the bullet and convert to structured FM. Increasingly few people can do so because the cost is so high, its hard to make a business case. I know I can't and I have looked into this extensively.  Adobe has tried to pretend that converting over to structured authoring is easy but in order to do this they have to have SEVEN webinars or a 7 hour training session just to give the basics!! While a huge change, I believe this one architectural change will provide the framework to address many of the other problems and competitive disadvantages framemaker has with other products out there. </font></span></div>
<div><span style="text-align:left;font-size:14px;line-height:21px"><font color="#333333" face="AdobeCleanRegular, Helvetica Neue, Arial, sans-serif"><br></font></span></div><div><span style="text-align:left;font-size:14px;line-height:21px"><font color="#333333" face="AdobeCleanRegular, Helvetica Neue, Arial, sans-serif">These other problems are: ve</font></span><span style="color:rgb(51,51,51);font-family:AdobeCleanRegular,'Helvetica Neue',Arial,sans-serif;font-size:14px;line-height:21px;text-align:left">rsion control, data structures, and publication formats.</span></div>
<div><span style="text-align:left;font-size:14px;line-height:21px"><font color="#333333" face="AdobeCleanRegular, Helvetica Neue, Arial, sans-serif"><div> </div><div>I currently place framemaker files in SVN and that works decently but because they are binary files I can't ever do diffs and FrameMaker's built in diffing capabilities is incredibly clunky and doesn't scale well at all. Furthermore, hello binary bloat in the source control repository. It would be amazing if instead I was committing XML files.</div>
<div> </div><div>In my opinion, FrameMaker's core competitive disadvantage is that the Book to PDF paradigm is dead. By that I do not mean PDFs and user guides are dead, I mean that instead of having only one format to publish to (PDF) and data structure (user guide or book) there are many other publication formats and data formats (e.g knowledge base) that are of co-equal importance.</div>
<div><br></div><div>As long as one stays strictly within book-to-PDF only paradigm, FrameMaker is awesome. The moment you go outside of that FrameMaker becomes very, very clunky, where you need to either use special tools (like Mif2Go) or use RoboHelp as a publishing engine (which has its own pain let me tell you).  One of the things i love most about FrameMaker is its powerful single sourcing capabilities. I want to use FrameMaker to be a single repository of all my content and I want to be able to publish that content in whatever format i choose. I believe one way to do this is to make FrameMaker a true XML authoring environment and use a powerful XSLT engine to convert the content into whatever format I want. The benefit of this particular approach is that its not just a solution but its an extensible framework. In theory, if the next hot format and data structure comes out tomorrow, I should be able to contract out,  design myself, or buy an XSLT that will generate the output that I desire.</div>
<div> </div><div>Put another away if I didn't need acrobat professional to handle PDFs, I would have switched to a tool like Flare a long time ago. If there comes a day when my audience no longer needs or cares about PDFs, that's the day I get rid of FrameMaker. That day isn't now but that could quite easily happen in the next 5 to 10 years. I really like FrameMaker but it has failed to stay current with the needs of technical communication industry and its only stayed alive because of a currently large dedicated user base and because PDFs are still one of the primary modes of communication.  I predict that when the later goes away so will the former unless Adobe can present a value proposition that no longer relies on vendor lock in and PDF usage.</div>
<div><br></div><div>Sincerely,</div><div>Joseph Lorenzini</div></font></span></div>