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: Fwd: DITA 2.0: Further Thoughts




Sent from my iPad

Begin forwarded message:

From: Shane Taylor <shane@taylortext.com>
Date: April 28, 2018 at 12:23:19 PM EDT
To: robander@us.ibm.com, Kristen James Eberlein <kris@eberleinconsulting.com>
Subject: DITA 2.0: Further Thoughts

First, I'm making inquiries if others at Cengage have interest in joining OASIS.

In the meantime, I'll add somewhat to the deluge of requests and inquiries I expect you're receiving about DITA 2.0 with a few other pain points from the field.

Prerequisite links
Often there are reasons to provide prerequisite links to topics that are not immediate siblings in a topic sequence. Doing so requires constructing that sequence in a reltable or otherwise with @processing-role="resource-only" and is cumbersome. 

One approach that I think would be simpler would be to allow specifying @role for a relationship table cell or column. I think this approach would be easier and more intuitive, and would allow defining other linking relationships without having to replicate the hierarchical structures. It does suggest looking at the current @role values — does anyone use "cousin" or "sample"? — and considering whether other values — maybe "application", "example", "main", "prereq", "postreq" — might be more useful.

@locktitle default value
This is a recurring pain point for me and for others: you specify navtitle metadata and realize you forgot also to set @locktitle="yes". I think the default value should be yes, so you can still choose not to use the specified navtitle (I'm not sure why you would), but it's assumed that if you added it you intended to use it.

key alternative definitions
I wonder if the approach being suggested to provide alternative image targets based on filtering metadata might also be used more generally for key definitions. A common use case is to define the key multiple times to point either to topics expected either to be in the current deliverable or externally, depending on the deliverable being built. Often, but not always, @deliverytarget is the defining difference. In some cases, it's @platform or other filtering metadata.

example before steps
Sometimes it's useful to provide a conceptual example to users in a task before users start the procedure. This can, of course, be done with section, but is there a compelling argument why example should not be allowed before steps? Related: consider replacing stepxmp with example in the same way we're replacing substeps.

context vs. section
Is there a useful semantic difference? Would it be terrible to remove context altogether in favor of the generic section?

Already mentioned my request for steps in chdesc to facilitate reuse and avoid tag abuse.

Shane Taylor


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