Topics

DITA: Fifteen(+) years old #history

Kristen James Eberlein
 

It's been 15 years since DITA was donated to OASIS, and next May will be the 15th anniversary of DITA's release as a standard.

I think it's fair to say that DITA is no longer a "shiny, new thing" but instead a mature XML architecture.

For those folks who've been around for a while, how well do you think DITA has lived up to its early claims? Has it addressed problems that it was designed to solve? Have other problems emerged? How is the landscape different in 2019 than it was in 2004?

--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

Rodolfo M. Raya
 

Hi Kris,

As an early adopter (from before IBM donated it to OASIS), I can tell you that DITA fulfilled its promises and today it is even better now than in the old days.

As time passed, the standard slowly grew and improved. The need for revisionism came and a much needed lighter version was drafted. There, in my opinion, appeared a problem when writing DITA stopped being an XML only thing. I personally don't like the idea of writing DITA in MarkDown or HTML5. Markdown is a great thing and HTML5 is also a great standard, but XML is a format much better defined for documents that need parsing and further processing before publishing.

DITA adoption is too tied to the DITA Open Toolkit. There are other processors out there but somehow the dependency on the Open Toolkit became generalized. In my view, this has been an obstacle for further adoption.

Your email made me realize that we owe a big thank you to IBM for opening DITA and another big thank you to OASIS for hosting it. 

A bigger thanks to the different chairs of the DITA TC and its siblings for a job well done.

Regards,
Rodolfo M. Raya







On Sun, Nov 17, 2019 at 12:34 PM Kristen James Eberlein <kris@...> wrote:
It's been 15 years since DITA was donated to OASIS, and next May will be
the 15th anniversary of DITA's release as a standard.

I think it's fair to say that DITA is no longer a "shiny, new thing" but
instead a mature XML architecture.

For those folks who've been around for a while, how well do you think
DITA has lived up to its early claims? Has it addressed problems that it
was designed to solve? Have other problems emerged? How is the landscape
different in 2019 than it was in 2004?

--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)






Kristen James Eberlein
 

Thanks for responding, Rudolfo.

I'm interested in trying to tease out how well DITA has answered the business requirements it was designed to address (some of which I think we take for granted in 2019) and what new things have emerged over the past 15 years.

Requirement DITA designed to address

I think of the following; can others add to the list?

  • Multichannel publishing
  • Effective reuse
  • Efficient, lower-cost translation
  • Ease of sharing source content with business partners
  • Expense of developing and maintaining proprietary XML grammars and the tools to work with them

Developments NOT on peoples mind 15-20 years ago

I can think of the following; can others add to the list?

  • Rise of Git and DevOps
  • Trend towards continuous integration
  • Development new career roles: Information architect, Metadata specialist

How well has DITA lived up to its promises?

Fairly well, I think. I do lack data and a method to quantify it. (Any ideas, here?)

One thing that I think have been extremely successful is growth of a very rich environment of DITA tools:

  • Editors
  • CCMS
  • Quality analysis and control applications
  • PDF rendering engines
  • Delivery platforms
  • Translation utilities

Yes, I do wish that there were more alternatives to DITA-OT -- and that more people contributed to DITA-OT! Folks might want to take a look at the video of my 2016 presentation at DITA-OT Day: https://www.oxygenxml.com/events/2016/dita-ot_day.html#Long_term_DITA-OT_planning

Other?

Hoping to hear from others in our community ...

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

Michael Priestley
 

Information architecture was part of DITA's original requirements - tying link management and navigation management to a common structural guide (DITA maps). That one I think we got mostly right, at least at the microsite level. I've got thoughts about DITA at the larger site level, where I think the standard is not necessarily a barrier, but maybe the way we're using it sometimes is.

One place where the promise hasn't panned out (yet, at least) is direct integration with web tech. At the time, XML was beginning to be supported for direct rendering in browsers, and that was definitely a trend we expected to continue. We hoped DITA might one day be a native web format, and direct rendering in the browser was one of our first use cases.

That said, we haven't given up on that yet - LWDITA's HDITA format is HTML5-valid, and still pursuing that dream.

Michael Priestley, Senior Technical Staff Member (STSM)
Information Architect, Marketing Analytics
mpriestl@...




From:        "Kristen James Eberlein" <kris@...>
To:        dita-users@groups.io
Date:        2019/11/21 09:10 AM
Subject:        [EXTERNAL] Re: [dita-users] DITA: Fifteen(+) years old
Sent by:        dita-users@groups.io




Thanks for responding, Rudolfo.
I'm interested in trying to tease out how well DITA has answered the business requirements it was designed to address (some of which I think we take for granted in 2019) and what new things have emerged over the past 15 years.
Requirement DITA designed to address
I think of the following; can others add to the list?
  • Multichannel publishing
  • Effective reuse
  • Efficient, lower-cost translation
  • Ease of sharing source content with business partners
  • Expense of developing and maintaining proprietary XML grammars and the tools to work with them
Developments NOT on peoples mind 15-20 years ago
I can think of the following; can others add to the list?
  • Rise of Git and DevOps
  • Trend towards continuous integration
  • Development new career roles: Information architect, Metadata specialist
How well has DITA lived up to its promises?
Fairly well, I think. I do lack data and a method to quantify it. (Any ideas, here?)
One thing that I think have been extremely successful is growth of a very rich environment of DITA tools:
  • Editors
  • CCMS
  • Quality analysis and control applications
  • PDF rendering engines
  • Delivery platforms
  • Translation utilities
Yes, I do wish that there were more alternatives to DITA-OT -- and that more people contributed to DITA-OT! Folks might want to take a look at the video of my 2016 presentation at DITA-OT Day: https://www.oxygenxml.com/events/2016/dita-ot_day.html#Long_term_DITA-OT_planning
Other?
Hoping to hear from others in our community ...
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting

www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)




despopoulos_chriss
 

I'm not a true old-timer in DITA, but I've been around markup since before XML (can you say Sounds Great Maybe Later). I think for your list of requirements DITA was designed to address, the results are generally good.  I will say that this one requirement has surprised me in practice:
"Ease of sharing source content with business partners"

My experience has not been so good. 

It's hard to break through silos within the enterprise.  Other teams don't naturally lean toward DITA, if they even know what it is.  The common information tooling (WIKIs, Slack, SalesForce, and other content monoliths) don't generally play well with DITA, and in fact some might see incentives not to play at all.  There are notable exceptions (ZoomIn for example).  But what I see as lacking is an ecosystem where DITA integrates easily with other systems.  Let's assume ZoomIn is perfect in every way (it could happen).  I still wouldn't be able convince my enterprise to switch from SalesForce/Atlassian/Drupal/Whatever.  There's too much inertia there.  So I need the integration ecosystem.

Likewise with cross-enterprise sharing.  Imagine my delight when I entered into an OEM relationship, and learned the other party used DITA.  Imagine my surprise when they announced that they cannot use my DITA in their publishing tool chain unless it LIVES in that system for the full lifecycle.  That's a complete non-starter for me. For them, tweaking the system to let me pour my content in on demand is too expensive.  I think this is related to the cost of a large-scale DITA deployment.  I'm in a start-up, and we're low-budget.  But high-budget systems seem to calcify, and the cost to break out of that is prohibitive.  Also, it seems to me that the high-budget vendors have an incentive to promote this calcification.  So even with DITA to DITA, you can run into a silo problem that is similar to the one I mention above.

I think you could quantify the enterprise silo problem by tracking how many DITA deployments reach out of the tech pubs department, and then look at how they achieve that.  Not sure how to track the cross-enterprise issues.  How many enterprises would share that kind of intel?  And also, how common is the need, really?  Aren't we more in a world of big fish eats little fish?  That's not sharing, it's absorbing...  A different issue (that DITA does indeed streamline).

I will say (message to Michael) that we do integrate directly with web tech.  We transform to HTML in the browser.  Not only can we display content in a specific browser app, but we use the same technique to display content in the product GUI.  So we can single-source between PDF, HTML, and micro-content in the GUI.  And we can filter or otherwise modify the content at run time.  I'm surprised this isn't happening more, and I expect LwDITA to promote this approach. 

I think the next step from this is open-source DITA editing in the browser.  It's already there for common Markdown, so it shouldn't be hard to do it for DITA. 

Kristen James Eberlein
 

Chris, thanks for chiming in. Lots of food for thought in your response.

I did want to quickly say that this thread is not only for "true old timers"; I'd like to hear from everyone. What do you think are DITA successes? Failures? Pain points? It would be good to keep the discussion within the context of a retrospective of how well DITA has accomplished what it was designed for.

I probably would not qualify as a "true old timer in DITA." My training is as a historian, and I migrated into technical communication when I went to work at IBM (as a contractor) in 2001. While I was part of a beta test of DITA in 2002, I did not start using DITA on a daily basis until 2005. I joined OASIS as an individual member in 2007, in order to be part of the Editorial Board for dita.xml.org, which was then a very active user site. In 2008, I became active with the DITA TC ...

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/22/2019 6:50 AM, despopoulos_chriss via Groups.Io wrote:
I'm not a true old-timer in DITA, but I've been around markup since before XML (can you say Sounds Great Maybe Later). I think for your list of requirements DITA was designed to address, the results are generally good.  I will say that this one requirement has surprised me in practice:
"Ease of sharing source content with business partners"

Chris Papademetrious
 

I became familiar with DITA less than two years ago. We wanted to migrate from structured FrameMaker to DITA for all the usual reasons, and I volunteered to investigate. I struggled to learn how DITA and the DITA-OT worked. I struggled with specialization. I didn't know Java or XSLT or Ant (still don't!) so many interesting things I found in discussion threads were beyond my abilities.

Gradually, I made progress. I abandoned DTD/XSD and embraced RelaxNG. After lots of Q&A with Eliot, I created a utility to automate specialization and I learned more about how DITA works in the process. I began migrating our FrameMaker books to DITA. So far I've converted 80 books in my development area, and we're doing a pilot project with five of the books to try DITA + Oxygen XML Author for production work. The writers in this pilot project absolutely love Oxygen's integration with Git, especially how easy its WYSIWYG conflict resolution is.

One of the things we like about DITA is specialization. I rejected the "specialize only if needed" approach and I specialized so that almost all the FrameMaker elements our writers are used to were recreated in DITA. I specialized attributes so that writers could intuitively control pagination and output formatting. I like knowing that we can plug this DITA grammar plugin into any DITA-capable authoring, management, or output tool.

We are frustrated that RelaxNG grammar support is not ubiquitous yet, but it's slowly getting there...

We're also looking at integrating many of our internal "style guide" authoring rules into Schematron, which will get integrated into our DITA grammar plugin. This is another plus that an XML-based format provides, as we previously used developed-in-house, manually-run tools in our FrameMaker flow.

There are many places where we want something different than the DITA-OT's default behavior - numbering, wording of certain builtins, etc. Currently I'm using a tremendous number of CSS kludges to force the PDF to our whims in Oxygen PDF Chemistry. But I'd like to learn how to write a DITA-OT plugin that does this in the processing pipeline, where it should happen. I'm struggling to figure out where to even get started, but I've struggled before and I eventually overcame. The same applies here.

We are aggressively using keyref-based references, including cross-book links. With Radu's help, I created a utility to implement cross-book links in XHTML and WebHelp output. We've run into authoring issues in Oxygen and publishing issues in the DITA-OT with cross-book links, but the only way to make progress is to push the boundaries, file issues, and hope for people smarter than you to fix them.

In my view, DITA continues to grow and develop in a positive way. Compared to being stuck in the same stagnant FrameMaker flows for years upon years, DITA and the freedom and flexibility it affords us is a breath of fresh air.

 - Chris