freelanceprogrammers.org Forum Index » XML / XSL
Considering DITA - Need more info... (SUMMARY OF RESPONSES)
Joined: 17 Jun 2005
Posts: 4
Considering DITA - Need more info... (SUMMARY OF RESPONSES)
Hi everyone, I posted these questions last week and have summarized the
responses I received. The responses are embedded with the questions.
Following the questions are a few paragraphs` worth of other information
people sent me. The original post is at the very bottom.
Thanks,
Susan White
Lexmark International, Inc.
Application Systems Analyst
* What caused you to switch from your custom DTDs to DITA?
-- People usually switch because DITA DTDs are cheaper and easier to
maintain. One reason is they are standard. Another reason is the object
oriented nature of DITA DTDs means you can make small changes without
breaking other parts of the DTD.
-- They [the consultant`s customers] never had their own DTDs.
* What benefits were there to switching from your custom DTDs to DITA?
-- See above. Also, you can focus on what is specific to your DTDs not on
the DTD infrastructure.
-- Perceived modularity and getting the authors away from the docbook type
way of writing material.
* From a DTD developer`s standpoint, how does maintaining DITA DTDs compare
to maintaining custom DTDs?
-- See above.
-- This was the first time I had seen DITA and I found it very difficult to
easily add in extensions to the base line. I have used TEI in the past and
that was very much easier to extend.
* From a stylesheet developer`s standpoint, how does maintaining DITA XSL
compare to maintaining custom XSL?
-- In some ways, cheaper. There is a lot of XSL that you don`t have to
write because it`s already written for you and because the OO DTDs mean OO
XSLs. For example, an element can be rendered with a parent element`s XSL.
Initial learning curve is a little steeper because in exchange for DITA
flexibility, you have more complexity. You have to deal with the class
attributes and conrefs and what not.
* From a writer`s standpoint, how does using DITA compare to using custom
DTDs?
-- Probably about the same, but ask a writer. Adobe and IBM are using DITA
extensively, and the writers are embracing DITA. Big reason: writers don`t
have to much with formatting anymore. They focus on information
development. It`s a more creative function.
-- Totally different way of writing the material.
* From a translator`s standpoint, how does translating DITA XML compare to
translate from custom DTDs?
-- About the same. But you need to set up your tool to filter a DTD and
you`d rather do it for a standard than for a custom DTD.
-- No real difference as both require reading to see what can happen where.
* What is the best thing about using DITA?
-- Business-wise: Reuse, in all its forms, leads to lower costs, shorter
turnaround, and higher quality. Technically: conrefs and OO DTDs are
technical innovations.
-- An Industry standard; combined effort of others to help iron out bugs,
details, develop transforms, etc.
* What is the worst thing about using DITA?
-- You have to break DITA (or add to it) to do anything useful with
attributes. The DITA committee is developing a solution to this right now.
The problem is that you can`t add arbitrary attributes like you can with
elements.
-- Not having specific Element names for specific constructs. For example
within a topic the Element is called a section, but as far as the author is
concerned it is a subsection by that time.
* What is your role (DTD developer, stylesheet developer, information
architect, author, translator, etc.)?
-- Pre-sales engineer. DTD/XSL developer.
-- DTD developer, conversion specialist and transformation
* What has your experience been working with translations vendors with
DITA-based XML?
-- Eliminates or greatly reduces DTP costs. Increases reuse and therefore
100% matches, thus lowers costs. Folks to ask include Adobe, Information
Builders (internal translators), IBM, and Nokia.
-- none
* Do you translate DITA maps? or just the topics?
-- Depends on what you put in your map. If there is translatable text
there, then you want to translate them.
* How many specialized topic types did you create? What were they?
-- Better answered by customers. We have created less than five specialized
topics for internal use. We also used the bookmap specialization which is
under discussion by the DITA TC.
* How many domains did you create? What were they?
-- None. Also, IBM recommends closely limiting the number of specialized
topics and domains you create. Only create them if you really can`t do what
you want to do without something new. Everything you create adds to the
cost of maintenance of your system. For example, cost of DTD creation, XSL
customization, and testing.
Additional information:
(1)
I am talking from my viewpoint of what I have ascertained from the client.
I know Adept have support for DITA and XMetal are on the verge of
announcing it (if they haven`t done so already). IBM have also issued a
number of scripts relating to conversion and transformation of DITA. Apart
from those I am not aware of any other tools to help you.
I must admit I have been in the DTD world for about 20 years now and when I
saw the DITA DTDs my immediate reaction was that this is yet another topic
based DTD. So I am not really sure what benefits your would gain,
ESPECIALLY as you have your own topic based DTDs, which presumably have
specific constructs peculiar to your business???
Your scenario seems very much like the Schema DTD discussion. Management
say "Schemas are at the forefront of technology and so we must use them".
You say "What does it give me extra does it give me" and in the majority of
cases nothing at all except having to redesign your system to accommodate
them !!!
(2)
My question is this .. why move to DITA if you have your own EDDs/DTDs? Is
there a business reason for this. TO me, it seems (not knowing the details)
a lot of extra money and effort will be spent to move to DITA -- and for
what business reasons?
Most folks who move to DITA move from unstructured non-XML world to DITA. I
haven`t heard of too many who move from company-specific EDDs/DTDs to DITA
-- at least, not without a sound business reason that would provide
measurable return on investment -- and provide benefits that the custom
DTDs don`t.
Not criticizing you, just trying to understand why you would want to make
such a move.
You already have the best of all possible worlds in your own in-house DTDs,
EDDs. DITA is a trendy topic for tech writers right now. Yes, it`s
valuable, as you noted, but unless the company goal is to burn a whole lot
of money for no return, I don`t think revamping everything for DITA is a
good thing.
I think The Rockley Group is busy writing a paper about DITA now and it
will likely include information on this very topic. I`ve written a few
articles about DITA (and had them reviewed by IBMs DITA team) but I haven`t
addressed this angle yet. I bet they`ll agree with me (and you) that you
aren`t missing out on anything.
(2 and 1/2)
Just wanted to say that I did some more research and thought about my last
response to you. Today, I stick by my initial comments and would add...
No way will you be missing out on any tool or industry support by not
moving to DITA.? DITA is just one standard in the landscape of XML. The
tool vendors will continue to grow their XML support, no matter where your
DTD comes from.
In fact, tool vendors are increasingly complaining that technical writers
and other content creators are forcing them to address specific DTDs /
architectures like DITA. This results in these companies creating material
that claim to be "DITA complaint" or that "support DITA" when in reality, s
DITA is XML, any authoring tool that supports your custom DTDs will also
support DITA.
I think your firm is ahead of the pack (by miles!) and are on the right
track already.
-------------------- Original post --------------------
Hi everyone,
We have developed our own topic-based DTDs and are now considering
converting to DITA. I am researching the pros/cons and have a few
questions for those of you who are currently using DITA. I really
appreciate your thoughtful consideration of these questions and look
forward to your responses.
* What caused you to switch from your custom DTDs to DITA?
* What benefits were there to switching from your custom DTDs to DITA?
* From a DTD developer`s standpoint, how does maintaining DITA DTDs
compare to maintaining custom DTDs?
* From a stylesheet developer`s standpoint, how does maintaining DITA
XSL compare to maintaining custom XSL?
* From a writer`s standpoint, how does using DITA compare to using
custom DTDs?
* From a translator`s standpoint, how does translating DITA XML
compare to translate from custom DTDs?
* What is the best thing about using DITA?
* What is the worst thing about using DITA?
* What is your role (DTD developer, stylesheet developer, information
architect, author, translator, etc.)?
* What has your experience been working with translations vendors
with DITA-based XML?
* Do you translate DITA maps? or just the topics?
* How many specialized topic types did you create? What were they?
* How many domains did you create? What were they?
Thanks,
Susan
All times are GMT
Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Freelace Website Designer - Customer web design and software building.
Booking Calendar - reservation calendar script
Land Surveying - total station instruments and equipments
China Wholesale - Electronics Products
Character Studio - Tutorials and Help
Booking Calendar - reservation calendar script
Land Surveying - total station instruments and equipments
China Wholesale - Electronics Products
Character Studio - Tutorials and Help