Autonumbering for task levels - EDD question

Question

Hello all,
In our current unstructured documents, we have a style that handles what we call "major" steps, which are tasks that can be by themselves or most often are no as they are normally in just one context. I could use <substeps> but the numbering scheme is reset, and these major steps normally involve a multitude of steps, not just one or two token sub-steps. Our major step is formatted like a heading, and there is a prefix of Step1 and StepN. We curently handle this using the Autonumber format in the paragraph designer (in our unstructured environ). In our structured DITA environment, I would like to retain that style since it is very popular with our users.
I am thinking that a change in the EDD is all I need as I could change the autonumber format based on a context. My question is, can I use a combination of {first}, etc ..rules with the ELEMENT < ELEMENT rule? My structure example appears below:
<task>
     <title>
     <shortdesc>
     <task>
With that second-level <task> being the MAJOR step. The highest level task is the MAIN user task, and would only required a <title> and <shortdesc>.
The Context rule "task < task" works for the first major step, but I need to handle the subsequent najor steps.
Any help or even an alternate way to handle this is greatly appreciated.
Thanks much
Tom

Answer 1

Tom,
  Sorry my response did not make it through. Thanks for letting me know. Here is what I wrote:
My question is, can I use a combination of {first}, etc ..rules with the ELEMENT < ELEMENT rule?
Tom,
  Yes, you can combine sibling and ancestor specifications. For example:
   x{first}
tests whether the current element is a child of an x that itself is the first child of its parent.
   {first} < x
tests whether the current element is the first child of an x. You can repeat the sibling specification after each ancestor listed:
   x{first} < y{first}
tests whether the current element is a child of of an x that is the first child of a y that is the first child of its parent. You can include wildcards in the ancestor chains, but you cannot test siblings of a wildcard:
   x{first} < * < y{first}
tests whether the current element is a child of an x that is the first child of its parent and that has an ancestor named y that is the first child of its parent. The y can be a more remote ancestor than the parent of the x. However:
   x < *{first} < y
does not work.
The Context rule "task < task" works for the first major step, but I need to handle the subsequent najor steps.
   task < task
tests whether the current element is a child of a task that itself is the child of a task. Whether either task is first is irrelevant. One mistake that is easy to make when writing such specifications is to use
  task < task
instead of
  task < * < task
These expressions differ because the first one requires there to be no intervening ancestors between the two tasks while the second one permits them.
Another easy mistake is to forget that the order of tests in a context rule is important. Suppose you
test
If context is: task
Else, if context is: task < task
Else, if context is: task < task < task
The else-if clauses will never fire because any element that is within three levels of task elements is also within two levels of task elements and any element that is within two levels is also within one level. Thus, any context that satisfies either else-if also satisfies the if. The if is used because it is first.
        --Lynne