In my ongoing evaluation all the DITA-capable XML editors (that I have
licenses for) with regard to the degree that they "just work", I can
report that OxygenXML Version 9 now comes very close to Syntext Serna
(still in the lead) with regard to its ability to automatically apply
its DITA functionality, including visual editing, to any DITA document
of any sort (including any specialized documents).

However, it does require that you make one not-necessarily-obvious
setting change in order for this to work.

By default, OxygenXML does not resolve DTDs before trying to determine
what editor configuration set to apply to it. This means that it will
likely fail to recognize local shells as being DITA document types
(because it won't see the DITAArchVersion attribute, which is the key
clue it uses to distinguish DITA from non-DITA).

You can, however, turn on DTD resolution in the configuration settings,
like so:

1. Go to Options->Preferences to open the Preferences dialog then select
the "Document Type Association" page.

2. Make sure that the user role selected in the "User Role" pulldown is
"Developer" (I think this is required).

3. Make sure that the "Enable DTD processing for document type
detection" check box is selected.

4. If you use DTDs that are served from a Web server, rather than being
maintained on your local machine, make sure that the "Only for local
DTDs" is unchecked. If you check this option, OxygenXML will not try to
resolve DTD references over the net, which can be a good thing if you're
working without a network connection.

5. Apply the new preferences.

You will also need to make sure that you've configured OxygenXML to tell
it where the entity resolution catalogs are (e.g.,
catalog-dita_template.xml) that it will use to resolve any references to
local shells. However, this step will be required by any editor
(including Syntext Serna). Catalogs are configured in OxygenXML under
XML->XML Catalog.

Once you've done this setup, you should be able to open any conforming
map or topic document, using any shell or specialization, and edit it in
Oxygen's new "Author" mode with appropriate styling applied and
DITA-specific functions available.

With Syntext Serna all you have to do is configure your catalogs, but on
the other hand, Serna may appear to lock up if you have a reference to a
DTD via a URL that can't be resolved (which is why OxygenXML's default
is to not resolve DTDs for doctype lookup). It won't have locked up, it
will just be waiting for the resolution attempt to time out, but that
might take 30 or 60 seconds, which is an eternity when you're waiting
for a document to open.

I think it's pretty cool that there are now at least two full-featured,
usable, low-cost, well-supported XML editors that have reduced the
needed up-front configuration for DITA support to the absolute minimum
possible (short of automatically discovering where your catalogs are).
This helps fully deliver on DITA's "[almost] zero cost of entry" promise.

I haven't yet had a chance to work with XML Mind or the latest version
of XMetal to see how their configuration processes compare--I hope
they're comparable but I'm not counting on it.

I will be doing some client work with Arbortext Editor very soon but I
don't think Arbortext's configuration mechanism has changed much in the
last year (it wasn't too bad but it wasn't yet fully automatic--but at
the time I last tried it it was the best, which says a lot about the
progress Syntext and SyncroSoft have made in improving their products).

I'll also be doing some client work with In.Vision's XPressAuthor for
DITA so I'll be able to report on that. Because of the nature of
XPressAuthor's integration with Word I expect that to be a bit more
involved--but just being able to do productive DITA authoring in Word
would be a big win for a lot of users and there's no real expectation
that something like XPressAuthor would be used as casually as Serna or
OxygenXML (or even Arbortext Editor or XMetal) would be. But in any case
I'll find out....

[NOTE: In both of these cases the client chose these products before I
was involved so do not take the fact that I'm doing paid work with them
as endorsements or evidence that I recommended them. Which is not to say
that I might not recommend them but such a recommendation would be based
on many variables specific to a given client. My intent is to know as
much as I can about all the available tools so that I can recommend the
best tool for a given client based on their specific needs. All of the
current crop of editors have strengths and weaknesses and unique
characteristics that will make them all appropriate choices for some and
not for others (even FrameMaker). There is no sense that any one product
is absolute "better" than any other products. If an editor product works
well enough to be considered at all it will be a best fit for somebody.]

As far as I know, FrameMaker is a lost cause--the reports I've had are
that it can't even handle local configurations, much less
specializations. But if I'm wrong about that please let me know.

Cheers,

E.

--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com