XML and FrameMaker

[mark.poston at mekon.com]

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.com at 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