The argument as to whether FM is a native XML editor has been running for 

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 

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.


Mark Poston

-----Original Message-----
From: at 
[] On Behalf 
Of Pedro Pastor
Sent: 17 January 2007 18:46
To: framers at
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:

Reply via email to