TC requests for proposal 13096

Hi Folks.

Here are the modifications needed for the Troubleshooting section proposal (13096: https://www.oasis-open.org/apps/org/workgroup/dita-techcomm/download.php/46342/TaskTroubleshootingSectionProposal13096.html) before next Tuesday's TC vote on the item.

Below are my notes; please be aware that I filled in memory/understanding gaps with my own opinions. Let's discuss this on the list for a few days before making these changes to the proposal.

1) Clarify the content model of the new element parent. Currently, there are references to "between <result/> and <postreq/>, but that does not indicate the the position relative to <example/>. My opinion for working this is:

"Proposal to add a new element to the task model called, "tasktroubleshooting". The new content model for would be:

( ( prereq) (optional) then ( context) (optional) then ( steps or steps-unordered) (optional) then ( result) (optional) then (tasktroubleshooting) (optional) ( example) (optional) then ( postreq) (optional) ) "

2) State explicitly that new element will be specialized from "section" and that it will have the same content model "example" (all "section" elements except for "title")

3) Under processing impact, change, "Style-sheets would have to add auto-generated text..." to "Processors may apply a label to content in this element to distinguish "Troubleshooting" information from other content.

4) Under "Attributes" modifications, change "None" to "Inherit same attribute definition as specialization base ("section").

5) Optional clarifications:

This change will be made to the "general" task, and we recommend that it not be constrained out by the "strict" task constraints domain.
The TC considered allowing a more flexible element ordering in "taskbody", but the guidance of the TechComm SC was that a rigid order was somewhere between acceptable and preferred.
The TC considered allowing the new element any number of times, but that was rejected. (Note, I dont remember the argument against allowing any number of times. I prefer having a more flexible content model because it opens the door for greater flexibility when filtering content based on select-atts. I defer to others on this matter, as I am not currently working with any troubleshooting content.

In other news....
The other two troubleshooting proposals (13098 and 13086) passed stage 2. To complete stage 3, we need 2 dedicated reviewers for each proposal. Please be thinking about your ability to commit.

Regards,

-seth

dita-techcomm message