OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Understanding DITA vs. DITA OT

As the person perhaps most squarely stuck in the middle of the two groups, I sketched out my thoughts on how DITA and DITA-OT overlap, or not. I drafted this before Kris suggested the committee note, but held off sharing for a few days because I spent waaaay too much time thinking about edits. Clearly these are my own thoughts, not the official position of either OASIS or DITA-OT:

I also agree that a committee note would be useful as a way to get more attention on this, and to have a handy link for anybody who gets this question (we're not going to stop getting this question any time soon).


Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group

E-mail: robander@us.ibm.com
Digital Services Group
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA

Inactive hide details for Kristen James Eberlein ---06/22/2016 09:12:16 AM---Great post, Tom. I have a very similar graphic thaKristen James Eberlein ---06/22/2016 09:12:16 AM---Great post, Tom. I have a very similar graphic that I use while explaining the components of a DITA

From: Kristen James Eberlein <kris@eberleinconsulting.com>
To: dita@lists.oasis-open.org
Date: 06/22/2016 09:12 AM
Subject: Re: [dita] Understanding DITA vs. DITA OT
Sent by: <dita@lists.oasis-open.org>

Great post, Tom. I have a very similar graphic that I use while explaining the components of a DITA implementation to clients and prospective clients.

Should the DITA TC consider doing a committee note about this? Everyone, please remember that we have the committee note mechanism to provide official communications between the DITA TC and the DITA community -- and this mechanism does not involve any OASIS approval.


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

+1 919 682-2290; kriseberlein (skype)

On 6/21/2016 4:32 PM, Tom Magliery wrote:

      Regarding the challenge of helping people understand the distinction between "DITA" and "DITA OT", here are some thoughts stemming from training new (to structured authoring) authors, parts of which some people find a little alarming, but all of which I cling to nerdily and stubbornly nevertheless. It starts with separation of structure and formatting. I use this premise to motivate a pair of diagrams, simple enough that I think you can get them from these verbal descriptions:
      1. For "traditional/DTP", there are two blobs in the diagram, one of which says "Authoring tool" and has an arrow pointing to the other, which says "Output".
      2. For "structured authoring" the "Authoring tool" blob yields a "Structured document", which sits next to another (originless) blob called "Style sheets". Both of these blobs feed into another one called "Publishing system", which in turn points to the final blob "Output".
      The mantra I use with these two diagrams is "With structured authoring you are not creating output; you are creating input." E.g., you are not saying "This stuff should have a box around it and be positioned over that-a-way"; you are only saying "This stuff is a sidebar". Then the publishing system says "Oh yeah, I know what to do with that."
      From there it is an easy step to discussing the following very real process, strongly similar to the code-test-debug cycle in programming:
      1. Write some code (XML/content).
      2. Generate output.
      3. Examine the output for correctness.
      4. Fix errors and go to step 2.
      I talk of the giddy anticipation when you're about to generate output again, the disappointment when it's still broken, and of course that eventual rush when you finally do get it right.
      The "fix errors" part is a burden potentially shared by both authors and style sheet developers, which does complicate matters. As far as the analogy goes, this can be handwaved a bit by the fact that we are teaching authors about their particular perspective on this ecosystem. But this also gives an opportunity to discuss the negotiations/compromises that sometimes must be made between markup design, markup usage, and style sheet development effort. (Similar negotiations may occur between product management and development in a programming shop, btw.)
      I think you could possibly push this analogy further with comparisons between DITA and programming languages, but I have not needed them, or thought them out enough to be sure how well it would work.
      While I admit that this analogy may be a little scary to folks who think programming is intimidating, I also think that it helps strengthen the basic premise of separation of structure from formatting that really is fundamental to understanding why DITA <> DITA OT. The cyclical process with "write code" and "generate output" in different stages reinforces that they are different parts of the system.

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]