Comparison of XML tools for writing documents
Andrea Leszek
Hi,
Our team is considering moving to XML-based documentation and we're
trying to pick a tool for content creation. Has anyone done research on
this already or know of a site that compares popular tools? I'd be very
happy to leverage any work that anyone else has already done :-) I've
been looking at Epic, Structured FrameMaker, XMLSpy, Xmetal.
Thanks.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
tech...@gts.org
To unsubscribe send a blank email to leave-techw...@lists.techwr-l.com
Send administrative questions to li...@techwr-l.com. Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.
Bruce Byfield
Andrea Leszek wrote:
| Our team is considering moving to XML-based documentation and we're
| trying to pick a tool for content creation. Has anyone done research on
| this already or know of a site that compares popular tools? I'd be very
| happy to leverage any work that anyone else has already done :-) I've
| been looking at Epic, Structured FrameMaker, XMLSpy, Xmetal.
Have a look at OpenOffice.org. It not only includes the option of
exporting to Simplified DocBook, but allows you to create XSLTs that can
be used with it. The interface is a normal word processor's, and, since
OOo's native file format consists of zipped collections of XML files,
the export is very clean.
--
Bruce Byfield
http://members.axion.net/~bbyfield
Geoff Hart
Andrea Leszek reports: <<Our team is considering moving to XML-based
Can't help you with the tools question, but I have a question of my
own: Have you actually done the necessary work to confirm that you need
an XML solution? If so, have you received the necessary training to
know how to create a useful document schema (i.e., a DTD) that will
meet your needs?
Sorry if that seems like an insulting question, but it's increasingly
clear to me that even the biggies (Microsoft, for instance, in adding
XML support to Word) are jumping on the software tools aspect of XML
and ignoring the more difficult aspect: the intellectual tools that let
you understand what you're doing and how to do it effectively.
XML is not just HTML with a new name: it's a whole other beast that
requires a whole new way of thinking about information. Do the thinking
_before_ you pick a tool. Once you understand what you need to
accomplish, and how XML lets you accomplish it, and it's relatively
easy to pick a tool that will let you accomplish it. Pick the tool
first and you'll end up in the proverbial "if all you own is a hammer,
everything looks like a nail" situation.
--Geoff Hart gh...@videotron.ca
(try geof...@mac.com if you don't get a reply)
Nagai, Paul
| Our team is considering moving to XML-based documentation and we're
| this already or know of a site that compares popular tools? I'd be very
| happy to leverage any work that anyone else has already done :-) I've
| been looking at Epic, Structured FrameMaker, XMLSpy, Xmetal.
Research we conducted a couple of years ago now, in front of a project to move several documentation suites into XML and a Content Management System, found FrameMaker lacking in the CMS-integration department. Further Frame did not work with and/or create and/or import native XML without effort. Finally, on a soft note, it perpetuated the format paradigm slowing the adoption of the content paradigm. There were other factors, of course, but those were the high level drivers of the decision to work with Epic instead. One post-implementation upside discovery about our choice is that customizing and extending Epic is much easier than FrameMaker.
I can't tell from your e-mail whether or not you have done this, but I think a move to XML-based documentation should be justified based on well understood requirements, savings and/or enhanced capabilities resulting from such a move, etc. XML for XML's sake is a money pit.
------
Paul Nagai
Tsunami relief portal:
http://www.networkforgood.org/
eric...@ca.transport.bombardier.com
bounce-tech...@lists.techwr-l.com wrote on 01/11/2005 10:44:58 AM:
| Research we conducted a couple of years ago now, in front
| of a project to move several documentation suites into XML
| and a Content Management System, found FrameMaker lacking
| in the CMS-integration department.
Well, is Astoria still available? Documentum certainly is. And a WebDAV
work environment could be implemented (although there seems to be issues).
| Further Frame did not work with and/or create and/or import native XML
without
| effort.
XML without effort? That's a pipe dream. To think that Epic is any less
effort is a joke. FOSIs and setting up each installation is no less (or
more) difficult than setting up templates and EDDs. In fact, I'd put the
advantage to FM as once you have templates and EDDs for deliverables, ANY
FrameMaker installation can produce required documents with only one being
tightly monitored for export to XML.
| Finally, on a soft note, it perpetuated the format
| paradigm slowing the adoption of the content paradigm.
Buzz words oft touted by Abortext sales people. It's rubbish and
completely meaningless.
You're only stuck in the "format paradigm" if your templates and formats
only reflect look and feel and not structure and content definition. You
can abandon the "format paradigm" without even adopting structure if you
name your styles correctly and make them hierarchical.
Once you have FM templates in place, you can beat recalcitrant writers
into place with little effort. Just change the configuration files to
remove access to the various formatting dialogs and options.
| There were other factors, of course, but those were the
| high level drivers of the decision to work with Epic
| instead.
| One post-implementation upside discovery about
| our choice is that customizing and extending Epic is much
| easier than FrameMaker.
Really? How so. I'd love to see real examples. The Arbortext guys failed
to show me anything that couldn't easily be accomplished in FM. Indeed
many of the required add-ons for Epic were built in to FM.
| I can't tell from your e-mail whether or not you have done
| this, but I think a move to XML-based documentation should
| be justified based on well understood requirements,
| savings and/or enhanced capabilities resulting from such a
| move, etc. XML for XML's sake is a money pit.
That I agree with.
Ease your way towards structure, much like you can ease you way to single
sourcing, by analysing your current data/content and redesigning your
templates and gathering system to reflect structures and content. Then,
when the time comes to structure the move will be painless.
If you can't get your team to work harmoniously with the concept of
structure now, you won't be able to impose effectively it with a jump to
an XML system without resistance and problems.
Eric L. Dunn
Senior Technical Writer
Nagai, Paul
|> Further Frame did not work with and/or create and/or import
|> native XML without effort.
| XML without effort? That's a pipe dream. To think that Epic is any less
| effort is a joke.
I never suggested an *XML solution* was achievable without effort. I intended to point out that Frame requires development time and money to create the EDDs and write rules in order to roundtrip XML. Epic does not since it works directly with XML.
| FOSIs and setting up each installation is no less (or more) difficult than
| setting up templates and EDDs.
| In fact, I'd put the advantage to FM as once you have templates and
| EDDs for deliverables, ANY FrameMaker installation can
| produce required documents with only one being tightly monitored for export
| to XML.
I would argue that FOSIs are costlier than FrameMaker templates by a long shot. I don't have enough experience with EDDs or write rules to factor them into a comparison.
Our requirements specified that XML be stored in a CMS with library control (checkout/checkin). This implies every author have the ability import/export (in Frame) XML. With Epic, there's no import/export since it works with native XML. Again, Frame does not integrate easily with CMSs. Yes, you can put Frame files into and take them out of any CMS outside of Frame, but pathing is tricky. Yes, you can modify Frame to add CMS capabilities to the menus. Epic provides an adapter for Documentum (the CMS we selected) that permits checkout/checkin (and other CMS functionality) from within the Epic client.
|> Finally, on a soft note, it perpetuated the format
|> paradigm slowing the adoption of the content paradigm.
|
| Buzz words oft touted by Abortext sales people.
| It's rubbish and completely meaningless.
As with generalizations, there is often a at least a kernel of truth underneath buzz words touted by sales people.
An authors way of thinking does change when shifting from authoring monolithic books to authoring chunks that are re-used across multiple books. Pick your buzz-words and vendors (or roll your own with free/share/open-ware), but this is true.
| You're only stuck in the "format paradigm" if your templates and formats
| only reflect look and feel and not structure and content definition. You
| can abandon the "format paradigm" without even adopting structure if you
| name your styles correctly and make them hierarchical.
| Once you have FM templates in place, you can beat recalcitrant writers
| into place with little effort. Just change the configuration files to
| remove access to the various formatting dialogs and options.
I agree with that. There are costs associated with that both up front and ongoing. Depending on requirements, that may be the way to go.
|> One post-implementation upside discovery about
|> our choice is that customizing and extending Epic is much
|> easier than FrameMaker.
|
| Really? How so. I'd love to see real examples. The Arbortext guys failed
| to show me anything that couldn't easily be accomplished in FM. Indeed
| many of the required add-ons for Epic were built in to FM.
Most of the customizations for Epic can be stored in a single location on the network accessed by all clients. Arbortext Command Language (ACL) is a scripting language through which tasks can be automated, menus/menu-items can be added/modified/removed, etc. Many of these things are possible with FrameMaker but at least some require third party tools and/or FDK-C/C++ skills.
No way to tell what category the features you consider important fall into.
| If you can't get your team to work harmoniously with the concept of
| structure now, you won't be able to impose effectively it with a jump to
| an XML system without resistance and problems.
I have no "answer" to this other than to state that while there were the usual "family squabbles" along the way, our authors participated in the requirements gathering, tool evaluation and selection, review of the detailed design, system testing, and final implementation.
I guess I should have said YMMV. ;)
------
Paul Nagai
Tsunami relief portal:
http://www.networkforgood.org/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Broberg, Mats
| Andrea Leszek wrote:
| Hi,
|
| Our team is considering moving to XML-based documentation and
| we're trying to pick a tool for content creation. Has anyone
| done research on this already or know of a site that compares
| popular tools? I'd be very happy to leverage any work that
| anyone else has already done :-) I've been looking at Epic,
| Structured FrameMaker, XMLSpy, Xmetal.
Andrea,
If you intend to translate your documentation into many different
languages, make sure you avoid Framemaker. Framemaker does not, repeat
does NOT, offer full Unicode support - which is of paramount importance
for streamlining translation flows.
Here's an excerpt from a Framemaker 7.1 product overview:
"Q. Does FrameMaker 7.1 support Unicode characters in XML files?
A. FrameMaker 7.1 software supports Unicode encoding for reading and
writing XML in Western European
and Asian languages including Chinese, Korean, and Japanese. Unicode
characters that do not map to the
FrameMaker internal character set are imported as FrameMaker markers and
exported intact when you
save your XML files. For more information on the international languages
in which you can author
FrameMaker documents, see the FrameMaker 7.1 FAQ at
www.adobe.com/products/framemaker."
If translation into many different languages is an important factor for
you, make sure you select a different XML authoring environment with
full Unicode support.
Best regards,
Mats Broberg
Technical Documentation Manager
www.flirthermography.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l
Technical Communication Certificate online - Malaspina-University College, Canada. Online training in technical writing, software (FrameMaker, RoboHelp, Dreamweaver, Acrobat), document & web design, writing manuals, job search. www.pr.mala.bc.ca/tech_comm.htm for details.
tom....@iwon.com
I have been documenting for three years in Epic Editor (Arbortext) with SigmaLink as the Document Management system. I like it but it takes some getting used to, like anything else. I don't know the costs or what is involved but I do know the style sheets take a bit of time to develop.
_______________________________________________
eric...@ca.transport.bombardier.com
Wow. Need to catch up with e-mails sitting in my Draft folder.
I got side-tracked by a similar discussion on Framers and forgot about
this one.
bounce-tech...@lists.techwr-l.com wrote on 01/11/2005 01:33:34 PM:
| I intended to point out that Frame requires
| development time and money to create the EDDs and write
| rules in order to roundtrip XML. Epic does not since it
| works directly with XML.
But, as you state further on EPIC requires development of FOSIs (as well
as other work) to be functional. So to base a decision to go with Epic on
these grounds would be a decision based on a pointless and inaccurate
comparison.
Besides, FM can be set up very easily to roundtrip with XML. Nothing
Arbortext said in a sales presentation convinced me that Epic was any
better in that regard. Actually, unless you have to REALLY roundtrip the
content, the numerous FM features can be leveraged until the move to XML
is absolutely necessary.
| I would argue that FOSIs are costlier than FrameMaker
| templates by a long shot. I don't have enough experience
| with EDDs or write rules to factor them into a comparison.
Seeing as I taught myself EDD and template creation and maintenance with
supplied manuals, I can attest that the effort is not rocket science. I
actually found it quite simple when requirements are defined. However, the
only references for FOSIs and Epic setup I could find required
multi-thousand dollar training sessions from Arbortext.
(There's also the not so small issue of Epic requiring yearly licence
fees.)
| Our requirements specified that XML be stored in a CMS
| with library control (checkout/checkin). This implies
| every author have the ability import/export (in Frame)
| XML.
As easy as "Save as XML". Or very easily simplified with minimal scripting
or FDK work.
| With Epic, there's no import/export since it works
| with native XML.
Complete rubbish. Epic still needs to process the data into and out of the
editing environment. I don't see how it has much of an advantage in this
case. The only advantage is the perception of seamlessness as the "save as
XML" is the automatic default.
The only person who can claim they're working with "native" XML is someone
who writes and tags in ASCII text.
| Again, Frame does not integrate easily
| with CMSs. Yes, you can put Frame files into and take them
| out of any CMS outside of Frame, but pathing is tricky.
Seems Adobe didn't do a good enough job implementing and then promoting
the WebDAV capabilities. I guess some big client out there is using it as
I doubt it would have been implemented unless requested.
| Yes, you can modify Frame to add CMS capabilities to the
| menus. Epic provides an adapter for Documentum (the CMS we
| selected) that permits checkout/checkin (and other CMS
| functionality) from within the Epic client.
FrameBridge is available for Documentum. I attended a sales seminar
jointly run by Documentum and Adobe and the implementation seemed
excellent. Actually it was a day after Arbortext presented Epic to us (and
they were in attendance at the FM/Documentum show). They were particularly
evasive (or downright wrong if you had any FM experience) when asked how
what was presented by Adobe and Documentum was inferior or more difficult
than what they presented using EPIC/E3.
| As with generalizations, there is often a at least a
| kernel of truth underneath buzz words touted by sales people.
But the solution required to address that kernel of truth is not always
what the salesman is selling. And sometimes it may be A truth, but an
insignificant one.
| An authors way of thinking does change when shifting from
| authoring monolithic books to authoring chunks that are
| re-used across multiple books. Pick your buzz-words and
| vendors (or roll your own with free/share/open-ware), but
| this is true.
Which is only true if you continue to have your authors work on monolithic
books and documents. Create authoring templates and VOILA! FM is producing
strictly chunks. You have to make the same conceptual change to your
templates, storage, and workflow regardless of which authoring environment
you choose.
If you don't have a "chunked" DTD, structure, and storage arrangement for
EPIC, you'll be just as monolithic with Epic as you are currently with FM.
| Most of the customizations for Epic can be stored in a
| single location on the network accessed by all clients.
Actually, one of the HUGE advantages to FrameMaker IMO is that once you
have a structured template created, no-one really needs access to anything
other than a standard installation of FrameMaker. Only one machine needs
to be set up to create the XML files.
Give someone a installation CD for FM, a structured template, and a quick
guide on how to tag and they can be productive on any computer in the time
it takes to install and open a new document.
| Arbortext Command Language (ACL) is a scripting language
| through which tasks can be automated, menus/menu-items can
| be added/modified/removed, etc. Many of these things are
| possible with FrameMaker but at least some require third
| party tools and/or FDK-C/C++ skills.
Well, FrameScript IS a third party tool, but VERY inexpensive. And the FDK
is well documented and easy to work with. C programmers are easy to find,
and once familiar with FrameScript the transition to C and the FDK isn't
too painful.
FrameSLT and other products greatly enhance the functionality and
possibilities as well.
I think that the spectre of "third-party" scripting tools versus native
tools is one of those useless inconsequential kernels of truth.
Another unjust and insubstantial spectre is the idea of finding
"FDK-C/C++" skills. ACL programmers aren't exactly a dime a dozen either.
Or the "difficulty of EDDs". Compared to the downright ease of FOSIs?!?
Give me a break. (my frustration is not with you, but with the sales goons
and the managers who make decisions based not on substance but on the
buzzword/minute ratio.)
YMMV,
Eric L. Dunn
Senior Technical Writer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l
Technical Communication Certificate online - Malaspina-University College, Canada. Online training in technical writing, software (FrameMaker, RoboHelp, Dreamweaver, Acrobat), document & web design, writing manuals, job search. www.pr.mala.bc.ca/tech_comm.htm for details.
---
Nagai, Paul
[ha! I just accidentally sent this to framers ;) doh!]
Before I address any specifics within your note, allow me to stipulate the following:
An Arbortext solution an Enterprise solution. To speak plainly, it will cost a lot of money. I would be surprised to find an Arbortext solution that didn't end up in the six figure range NOT counting the internal resources of the customer. FOSI development and maintenance, if required, very well may be an ongoing cost (that is, it is never internallized by the customer). All Arbortext software licenses require annual maintenance fees. Well, if you want support and/or upgrades. I don't think Epic stops working if you stop paying, but you don't get upgrades or support.
bounce-tech...@lists.techwr-l.com wrote on 01/11/2005 01:33:34 PM:
| > I intended to point out that Frame requires
| > development time and money to create the EDDs and write
| > rules in order to roundtrip XML. Epic does not since it
| > works directly with XML.
|
| But, as you state further on EPIC requires development of FOSIs (as well
| as other work) to be functional. So to base a decision to go with Epic on
| these grounds would be a decision based on a pointless and inaccurate
| comparison.
Of course. I do not think I suggested anyone do so.
Everyone: Please do not base six-figure decisions and multi-year projects on a single paragraph of any one of my e-mails. Phew! Millions saved!
But seriously, raising the FOSI cost issue here distracts from my original point: Creating EDDs and write rules in order to round trip XML (presumably between Frame and some other application that will likely have requirements on that XML) takes time and money. I don't doubt that FrameMaker can Save As XML. I suspect, however, that if your XML must be handled by multiple applications, you will have to spend some time understanding FrameMaker's XML limitations, tuning EDDs, write rules, and your other XML application(s), and maybe some creating/using something (XSLT?) in between. Plan for it.
| > Our requirements specified that XML be stored in a CMS
| > with library control (checkout/checkin). This implies
| > every author have the ability import/export (in Frame)
| > XML.
|
| As easy as "Save as XML". Or very easily simplified with
| minimal scripting or FDK work.
Yes, but paired with the requirement I mentioned elsewhere (authoring environment-CMS-integration), Save As XML nor scripting were satisfactory.
| > With Epic, there's no import/export since it works
| > with native XML.
|
| Complete rubbish. Epic still needs to process the data into and
| out of the editing environment. I don't see how it has much
| of an advantage in this case. The only advantage is the
| perception of seamlessness as the "save as XML" is the
| automatic default.
Provide Epic with a DTD and a matching XML file, and it can open, edit, and save that XML file. My understanding is that FrameMaker would require EDDs and write rules to be able to do that. Am I wrong?
| The only person who can claim they're working with "native"
| XML is someone who writes and tags in ASCII text.
Maybe I have misused language somewhere, but there is a class of tools that I would say work with native XML: XMLSpy, Epic, etc. The open, edit, validate, and write out XML based on the XML itself and a DTD. FrameMaker is not in that class.
A powerful text editor (I like Textpad) is a valuable tool in the toolbox of every person supporting an XML environment. Don't, however, fail to distinguish between modifying XML files with a text editor and editing XML. Maybe I'm making something up here, but there is a difference. Using your text editor *you* are responsible for the validity of that file when you are done. With an XML editor, *it* is responsible for validity. I'm not sure that I would say editing XML *files* with a text editor is working with native XML in the context of an "XML editor discussion." But hey, that's semantics ...
| > Yes, you can modify Frame to add CMS capabilities to the
| > menus. Epic provides an adapter for Documentum (the CMS we
| > selected) that permits checkout/checkin (and other CMS
| > functionality) from within the Epic client.
|
| FrameBridge is available for Documentum. I attended a sales
| seminar jointly run by Documentum and Adobe and the
| implementation seemed excellent.
Do you mean FrameLink?
http://www.datalogics.com/framelink.asp
At the time we did our research both Adobe and Documentum reps were lukewarm, at best, about this product. FrameLink's own website at that time was at least a whole FrameMaker version behind. Their site currently refers to Frame 6 and Documentum 4.
If you really did mean FrameBridge, please provide a reference. Searches on Documentum, Adobe, and Google don't turn anything up.
| > An authors way of thinking does change when shifting from
| > authoring monolithic books to authoring chunks that are
| > re-used across multiple books. Pick your buzz-words and
| > vendors (or roll your own with free/share/open-ware), but
| > this is true.
|
| Which is only true if you continue to have your authors work
| on monolithic books and documents. Create authoring templates
| and VOILA! FM is producing strictly chunks. You have to make
| the same conceptual change to your templates, storage, and
| workflow regardless of which authoring environment you choose.
I don't remember exactly how this conversation drifted into the discussion of chunk-authoring. My original point was, I thought, that I believe that the formatting feedback provided by FrameMaker slows the adoption of a "think content" mindset. I accept that your experience and the experience of authors you work with may be different.
| I think that the spectre of "third-party" scripting tools versus
| native tools is one of those useless inconsequential kernels of truth.
Fair enough. I would suggest, however, that there is an upside to having the scripting language owned, upgraded, and supported by the same vendor producing the editor. That upside comes at a cost. See previous stipulations.
| Another unjust and insubstantial spectre is the idea of finding
| "FDK-C/C++" skills. ACL programmers aren't exactly a dime a dozen
| either. Or the "difficulty of EDDs". Compared to the downright ease
| of FOSIs?!?
ACL scripting is fairly straightforward. Anyone comfortable with javascript will be able to maintain, if not create, most of the customizations required. This is not to say that ACL is not powerful or that extremely complex applications can't be created within it ... just that there is a lot of low hanging customization fruit accessible to ACL.
I have also developed FDK-c/c++ customizations for Frame (although it has been a while ... they were for v5.5.6). ACL was easier for me to pick up than the FDK stuff. Admittedly, though, the c/c++ required to do FDK work is at the lower end of c/c++ skills.
FOSI work is in a class by itself. Expensive. Complicated. Twitchy. And, not a useful skillset outside of the Arbortext world. That said, newer Arbortext tools (Styler) are addressing this problem. Also, Epic is not tied to FOSI for print stylesheets. XSL/FO is also supported.
Can spectres be unjust? I'd say they were unholy. Someone considering migrating to an XML environment should consider where they want to spend how much money for what deliverables AND their available resources, skillsets, standards, etc. If you've got spectres, call a spectre-buster.
| Give me a break. (my frustration is not with you, but with the
| sales goons and the managers who make decisions based not
| on substance but on the buzzword/minute ratio.)
Hey, some of my best friends are sales people (and managers)! Arbortext is as guilty as any other software company of trying to tell their story and convert listeners to customers. If you're in the market to replace FrameMaker (structured or otherwise) with an XML editor, you've got to talk with Arbortext. You don't have to buy their story, though. Nor should you buy ANY XML story unless you've got a story of your own that has already convinced someone with money that you've got something to gain (or stop losing) by making that change.
Hopefully the Eric and Paul show has been illustrative for all you kids out there! Hey Eric, maybe we could turn this into a road show. Get invited to conferences. Wined and dined. Which of us gets to be Dan Aykroyd! ;)
Cheers, all.
------
Paul Nagai
Tsunami relief portal:
http://www.networkforgood.org/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
qui...@airmail.net
At 10:51 AM -0800 1/20/05, Nagai, Paul wrote:
|
|
|Provide Epic with a DTD and a matching XML file, and it can open,
|edit, and save that XML file. My understanding is that FrameMaker
|would require EDDs and write rules to be able to do that. Am I wrong?
|
|
|> The only person who can claim they're working with "native"
|> XML is someone who writes and tags in ASCII text.
|
|Maybe I have misused language somewhere, but there is a class of
|tools that I would say work with native XML: XMLSpy, Epic, etc. The
|open, edit, validate, and write out XML based on the XML itself and
|a DTD. FrameMaker is not in that class.
You only have to use EDD in FrameMaker to format printing. The XML is
written in TEXT, and the code is validated in FrameMaker using your
DTD.
|A powerful text editor (I like Textpad) is a valuable tool in the
|toolbox of every person supporting an XML environment. Don't,
|however, fail to distinguish between modifying XML files with a text
|editor and editing XML. Maybe I'm making something up here, but
|there is a difference. Using your text editor *you* are responsible
|for the validity of that file when you are done. With an XML editor,
|*it* is responsible for validity. I'm not sure that I would say
|editing XML *files* with a text editor is working with native XML in
|the context of an "XML editor discussion." But hey, that's semantics
|...
|
|
|> > Yes, you can modify Frame to add CMS capabilities to the
|> > menus. Epic provides an adapter for Documentum (the CMS we
|> > selected) that permits checkout/checkin (and other CMS
| > > functionality) from within the Epic client.
If you are saving as XML, you have a text file. Use any blinking
versioning software you want.
That is my take on this. Anyone else have their 2 cents worth to add?
Scott
Broberg, Mats
eric...@ca.transport.bombardier.com wrote:
| > With Epic, there's no import/export since it works with native XML.
|
| Complete rubbish. Epic still needs to process the data into
| and out of the editing environment. I don't see how it has
| much of an advantage in this case. The only advantage is the
| perception of seamlessness as the "save as XML" is the
| automatic default.
Far from "complete rubbish".
Software that works with, and fully supports, native XML files - as
opposed to software like Framemaker - does not "process" the data into
and out of the editing enviroment. They merely apply a screen stylesheet
on the XML data to make the editing more user-friendly. This does
nothing to the XML files themselves.
The advantages are clear - no read/write rules, no re-mapping of Unicode
to some propriety internal character encoding, no propriety internal
element definitions (like Framemaker's EDD) etc. It's a tad unfair -
both to fully XML / Unicode compliant software and to "me-XML-too"
software like Framemaker - to compare the both.
Framemaker may work very well for projects where issues like
translation, automation, and integration to other systems and workflows
are not very important. But it is not the way to go if these issues are
important and one is very serious about setting up an XML workflow. If
this is the case, the way to go is solutions that fully supports XMl /
Unicode - e.g. Epic Editor, XMetal, XML Client etc.
Best regards,
Mats Broberg
Technical Documentation Manager
FLIR Systems AB
eric...@ca.transport.bombardier.com
bounce-tech...@lists.techwr-l.com wrote on 01/21/2005 02:32:59 AM:
| eric...@ca.transport.bombardier.com wrote:
| Software that works with, and fully supports, native XML files - as
| opposed to software like Framemaker - does not "process"
| the data into and out of the editing enviroment. They merely apply a
| screen stylesheet on the XML data to make the editing more
user-friendly. This does
| nothing to the XML files themselves.
Hmm. It may be semantics, but to me it seems that they're just doing what
FM does with Read/write rules "on-the-fly" and there's no
"work-in-progress" intermediate file format to save.
That has the disadvantage that any functionality you could gain from an
application that isn't supported in XML can't be leveraged.
| The advantages are clear - no read/write rules, no re-
| mapping of Unicode to some propriety internal character encoding, no
| propriety internal element definitions (like Framemaker's EDD) etc.
Uhmm, there's no "propriety internal element definitions". An EDD is just
a merged DTD and stylesheet.
| It's a tad unfair -
| both to fully XML / Unicode compliant software and to "me-XML-too"
| software like FrameMaker - to compare the both.
I think Unicode support is probably the big Achilles heel of FrameMaker.
The Frame character set and the limitations placed on some non-structured
functionality (for example running headings are limited but their
structured equivalent, elements that pull their information from other
elements, are unlimited) are unfortunate holdovers of an old code base.
But, are the Unicode workarounds really that onerous? Or are the
shortcomings based on the view that the information must ALWAYS be stored
in xml and always be capable of "round-tripping" through multiple
modifications?
| Framemaker may work very well for projects where issues like
| translation, automation, and integration to other systems
| and workflows are not very important. But it is not the way to go if
| these issues are important and one is very serious about setting up an
XML
| workflow. If this is the case, the way to go is solutions that fully
| supports XMl/Unicode - e.g. Epic Editor, XMetal, XML Client etc.
Analyse the need for "translation, automation, and integration to other
systems and workflows" and how your setup needs to work before believing
the XML gurus. We were told at one time that the ONLY way was to build an
SGML repository into which all work would be fed and then paper, pdf, and
IEM output would be generated. The end result was it was much more
efficient to have our internal information pass from FrameMaker to print,
pdf, and the repository. The repository was then only for producing the
IEM.
Even when multiple vendors are required, the repository approach was not
necessary. Unless the workflow requires the integration of multiple
authors on single sources, the round-trip equation often doesn't add up.
Eric L. Dunn
Senior Technical Writer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^