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] Review of Lightweight DITA

Dear Dawn and all,

I think your questions are highly valid, and if the committee note did not persuade you to embrace LwDITA, then it is our rhetorical fault and we have to strengthen the topics that explain LwDITA's audiences and purposes.

To a degree, there is plenty of Information Typing (IT) in LwDITA. The lw-topic is a valid information type and small companies (or even teams of one or two writers) can create their structures without DITA constraints. That sounds like a blasphemy opening the door to spaghetti paragraphs and lists... but isn't that already allowed in DITA through specialization? Sure, the spaghetti becomes constrained and more structured, but team X's specialized topic can be as messy (or as efficient for their unique purposes) as team Y's lw-topic.

And here we are going for audiences that, let's be honest, would not adopt DITA's semantic tags for many reasons. Maybe they are web writers comfortable with HTML but scared or unfamiliar when it comes to XML. Maybe they are developers who write in Markdown but want to take advantage of DITA's reuse and publishing features but do not need semantic tags. Maybe they are non-English-speaking authors who can be comfortable in a reduced semantic soup of English words and terms.  

You mention that semantic tagging has been an entire educational process, and that is true indeed. However, how about those users who can be taught to see the DITA-like structures without needing the training wheels that come with XML tags? Again, these will be authors in very small teams or departments that do not need serious structural enforcement, but can benefit from many aspects of DITA. In many courses, I start teaching those rhetorical commonplaces of genre or type before we even see any XML tags. It works for many students. Of course, expecting that a tech writer who has been doing things a certain way for 20 years will suddenly change without the restrictions of DITA 1.3 is a bad idea... but then again 1.3 is not going away and 2.0 is coming soon.... ish.



Carlos Evia, Ph.D.
Director of Professional and Technical Writing
Associate Professor of Technical Communication
Department of English
Center for Human-Computer Interaction
Virginia Tech
Blacksburg, VA 24061-0112

On Fri, Jun 23, 2017 at 6:45 PM, Dawn Stevens <dawn.stevens@comtech-serv.com> wrote:
Hi all,
In my review of the document and the copious amounts of comments made already, I don’t know that I have anything more to add that hasn’t already been said. I completely agree with most of the comments made by all.

I have my own personal issues that I’m not sure are worth discussing, since I am sure they’ve been debated before and I’m sure people much smarter than me and more experienced in this area have already had these debates. But for the record, here are my bigger issues. If anyone wants to respond to me privately, I’m happy to get more understanding; it certainly feels that I’m the only one who is struggling with these fundamentals, and perhaps it’s just indicative of being late to the party and not really following any of discussions early on since JoAnn was our representative.
  • IT stands for information typing. There is no such thing in lwDITA — everything’s a topic. To me this is part of the essence of DITA and something I am frequently trying to educate my clients about — why everything just shouldn’t be a concept, why it’s important to determine what type of content you are writing. Now they’re going to have permission to do just what I’ve taught them not to do.
  • It seems that what lwDITA boils down to is the elimination of semantic tagging, which again, has been an entire educational process — why is it important that it’s not just a paragraph, but a context paragraph — I’ve worked with my clients to explain why it’s better to tag content not just on what it is or how it looks, but what purpose it serves. When purpose is clear, following the template and structure become easier, and more consistent. Eliminating semantics in my opinion opens the door to just having a topic with a bunch of paragraphs in it, without structure and consistency. 
  • 100% of my clients use <table>, not <simpletable>, to meet their needs. It seems a shame that this one thing will keep them from an lw solution if they otherwise wanted the simplicity.

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