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] Potential stage 1 proposal, let steps element nest

I like the idea in theory, and have indeed come up against some of the issues Robert listed as counterarguments — the difficulty with conrefs and with moving steps around in a hierarchy.

However, one benefit of substeps is that it is easier to constrain them out if you only allow one level of steps. I’ve done this in the past, and I would suspect that others have too. Would turning off nesting altogether count as a valid DITA constraint? I recall that there is some trickery with another attribute to allow or disallow task nesting in DTDs — would the same be needed on steps if they were defined as nestable in the standard? (DTDs are still important in practice, I feel, as few tools have moved to RELAX NG.)


On Jul 21, 2017, at 14:24, Bob Thomas <bob.thomas@tagsmiths.com> wrote:

I will put this on the agenda for next Monday's meeting of the Technical Communications Subcommittee.

Best Regards,
Bob Thomas
Tagsmiths, LLC

On Fri, Jul 21, 2017 at 1:24 AM, Jang <jang@jang.nl> wrote:
I support the idea, as it would simplify many things. There is no good reason to treat step and substep differently, except avoiding unlimited levels of nesting. That is not something to handle in a standard like DITA - it should be part of content strategy training and it could be handed to authors as guidelines.

On 21 Jul 2017, at 00:16, Robert D Anderson <robander@us.ibm.com> wrote:

Having just sent in regrets for next week, I'm going to stir the pot with a controversial idea.

I've been asking IBM authors what they want from DITA 2.0. One of the more common responses so far is "get rid of substeps" -- meaning, just let <steps> nest.

The reason we have <substeps> is so that task can enforce (what DITA 1.0 designers considered) good information design. That is: if you've got three levels of nesting, that's too much for a single task, and you should break the task apart. If <steps> nests, that allows task to have 3 or 5 or 20 levels of nesting, just as with <ol>.

I've heard several counter-arguments in the last few days:
- There is no semantic difference between step and substep, so it's frustrating to have two sets of elements
- It prevents copy/paste or drag/drop if you try to turn one into the other
- If a step in one task is reused as a substep in another, you cannot conref the whole step - instead you have to conref every child of the step
- The limitation isn't even effective, because people just put <ol> inside the substep's <info> element
- If an author / a team / a company want to limit nesting, there are other ways to do that, such as Schematron rules or build / formatting rules

Given the design history and potential migration cost, I didn't think the TC would look kindly upon this idea, but then the arguments started to pile up, and I wondered if the rest of you were hearing the same thing.

Curious as to your thoughts...


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

Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)

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