dita — archive

[Kristen Eberlein]

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