Bug 4804

Summary: Split-level flow (child of split) transitions are invalid
Product: jbatch Reporter: ScottKurz
Component: sourceAssignee: cvignola
Severity: enhancement CC: issues
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Windows   

Description ScottKurz 2013-03-16 19:19:45 UTC
I know we've been back and forth in and out of this type of issue, (e.g. Bug 4234).

   <split id="split1">
      <flow id="flow1" next="step1">
	<step id="flow1step1" next="flow1step2">

The <flow>'s @next is meaningless.   

So this raises two other questions:

1) Can the split-level flow do a stop/end/fail?   

2) Say we say "flow within split cannot next.." 
This raises a point we keep getting back to w.r.t. the TCK... can the TCK test for either JobStartException or BatchStatus.FAILED?   What if a runtime wanted to just ignore this?  Does that imply semantic-validation tests aren't desirable?
Comment 1 ScottKurz 2013-03-16 21:24:28 UTC
I wouldn't mind being strict here and saying that the flow cannot have a @next attribute or any transition elements.   

An alternative of course is that any flow in a split can stop or fail the whole split through JSL.   I think we could take a stab at that since we're in this code anyway but it's likely to be undertested by the TCK.
Comment 2 cvignola 2013-03-16 21:54:40 UTC
1. Since the spec says semantic validation is done at the discretion of the implementation, the TCK should really stay clear of semantic validation.

2. If we add this one semantic requirement to the spec - i.e. next= is not allowed on a split-flow, what rationale do we have for not specifying other semantic requirements?

3. I wanted to shy away from enumerating all possible semantic requirements, because it would significantly increase the spec and TCK without providing any real value.

4. The semantic requirements naturally fall out of the decisions an implementation must make in order to process the job, so I don't think that's too big of a problem.

5. I can see the spec is under-specified in this regard, however:  it fails to state what occurs if a JSL element specifies both the next attribute and the next element.  I think the right answer for that is:  the transitions elements take precedence;  if none of them apply, then next= (if specified) is used. If there is no transition, then it is end of job.
Comment 3 ScottKurz 2013-03-16 22:40:25 UTC

This isn't purely a question of whether the TCK should test for JSL we all agree "shouldn't work".  

I'm also raising the question "can a split-level flow end/fail/stop a job"?
Comment 4 ScottKurz 2013-03-16 22:52:53 UTC
And the spec is NOT underspecified w.r.t. using next attribute and next as transition element.

It clearly says you cannot mix and match.. implying it's some type of error.

You're actually throwing a new behavior into the mix at the last minute...
Comment 5 cvignola 2013-03-18 16:56:38 UTC
I forgot about the statement in PFD v1.6 section 8.2.5 Step Sequence that says:

"The next attribute and next element may not be specified together in the same step."

The combination of the two is a semantic error in the JSL and can be dealt with in an implementation specific way, as per 13.1 Validation Rules. 

So you can ignore list item #5 in comment #2.