Re: [dita] Potential stage 1 proposal, let steps element nest

["Robert D Anderson" <robander@us.ibm.com>]

For what it's worth - Jang's right that the constraint would be no more difficult. Where today you update the content model of <step> to disallow <substeps> as a child, you would update it in the same way to disallow <steps>.

I've gotten a couple of responses off the list that had either an ambivalent or positive take on this.

Based on those responses, I think some may have understood my initial suggestion as "just get rid of <substep> but keep the <substeps> container". It's not what I meant, but I suppose that would be another alternative -- if <substeps> had <step> as a child instead of <substep>, it would resolve most of the issues I laid out. That said, my original intention was to get rid of both the <substeps> container and the <substep> element, replacing both by allowing <step> to have <steps> as a child.

Regards, 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

Jang ---07/21/2017 10:53:13 AM---Hi Joe, It should be just as easy to constrain a step out of a step, I think. In any case, I would n

From: Jang <jang@jang.nl>
To: OASIS DITA TC List <dita@lists.oasis-open.org>
Date: 07/21/2017 10:53 AM
Subject: Re: [dita] Potential stage 1 proposal, let steps element nest
Sent by: <dita@lists.oasis-open.org>

---

Hi Joe,

It should be just as easy to constrain a step out of a step, I think. In any case, I would not take easier constraints work or lack of tool sophistication as a valid argument for cleaning up some conceptual issues in the standard.

My 2 cents, or 4, if you count the previous ones as well :-)

Jang

On 21 Jul 2017, at 17:19, Joe Pairman <joe.pairman@mekon.com> wrote:

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.)

Thanks,
Joe



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...

Regards, Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification, Digital Services Group	<ecblank.gif>
E-mail: robander@us.ibm.com Digital Services Group	<17306364.gif>
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)