[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] FW: DITA 2.0 troubleshooting: diagnostics_general OR diagnostics_steps (not both)?
I found the Diagnostics proposal, which of course addresses the requirement I expressed below for a way to capture diagnostics processes separate from cause or remedy. Looking at it now I would think allowing <-div> before the steps in diagnostics steps would be reasonable, or maybe something like <diagnostics-overview> (specialized from <div>) , with a documented intent that it is for things like flow charts and similar non-list representations of diagnostics processes. Cheers, E. -- Eliot Kimber http://contrext.com From: <dita@lists.oasis-open.org> on behalf of Eliot Kimber <ekimber@contrext.com> Looking at the original paper and Silkeâs comments, my first impression is that there is not a clear distinction between âcauseâ and âremedyâ in the complex example but then looking at it more deeply I think the problem is really that there needs to be nested troubleshooting topics, one for each actual cause determined via the flow chart. I read the flowchart as âuse this flow chart to determine the causeâ, which suggests itâs appropriately in the cause section, but then the steps, which are in the remedy section, repeat the spreadsheet, so they are again really telling you how to determine the cause of the problem and thus cannot be the remedy. I do not see any remediation information that you could then perform in response to having determined the cause via the flowchart and steps, but that may simply be because it was omitted from the example. It feels like thereâs a feature missing, namely some form of âcomplex cause determinationâ component. But in general reading it now, Iâm not at all happy with how the sample content was mapped to the troubleshooting markup in the paperâit doesnât seem to be a good fit. The example represents a number of distinct causes, each one of which presumably has its own remediation steps. Thus, I would expect to have a top-level topic that represents the cause (âinsufficient voltage alarmâ), describes the process for determining the specific cause, and then in the remedy section has a statement to the effect of âSee the following cause-specific troubleshooting topics for each possible causeâ. For each cause as determined by the flow chart you then have a nested troubleshooting topic for that specific cause (i.e., Faulty LN243 pack or Excessive line noise). The only change that might suggest is that <cause> should allow <steps> but I havenât thought that through. Cheers, E. -- Eliot Kimber http://contrext.com From: <dita@lists.oasis-open.org> on behalf of Kristen James Eberlein <kris@eberleinconsulting.com> Info from Silke Achterfeld about troubleshooting requirements. I also asked her for another example. Best,
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]