Template:— referencing_task (ref_task) Date: 2008/03/08 23:09:43
Revision: 1.18
CoverContentsDescriptionModel diags.Input params.Ref. params.Instantiation pathInstance diags.CharacterizationsIssues

Issue raised against: referencing_task

GENERAL issues

Closed issue Issue: RBN-1 by Rob Bodington (07-06-27) minor_technical issue
Resolution: Accept. Status: closed

The identification of the variant of the task should be optional. Not all tasks will be variants.
Comment: (Bill Nairn 07-06-29)
Task variant has been made optional. A characterization diagram (Figure 5) has been created to reflect this and the optional constructs have been removed from Figure 1. To close this issue, the six parameters associated with the task variant need to be removed from the template.
Comment: (Sean Barker 07-10-03)
Task variant has been removed and another template referencing_task_with_variant proposed. The approach of using characterization to add a variant id is WRONG, since it conflicts with the requirement that such variants must be unique

Closed issue Issue: BNN-1 by Bill Nairn (07-06-29) minor_technical issue
Resolution: Accept. Status: closed

Changes made to date - re-vamped Figures 1 and 2 (Express-G and Template summary) also added figure 5 (characterizations).

Closed issue Issue: BNN-2 by Bill Nairn (07-06-29) minor_technical issue
Resolution: Accept. Status: closed

Remaining work required in readiness for DNV review: Remove parameters (see RBN-1); correct the instance files in line with task variant now being optional (ditto for template summary, figure 2); move descripion text relating to characterization (i.e. task variant) from the top of the diagram to the characterizations section; correct rdl errors in the template; finish identification of master files in the template XML; complete the standard checks (spelling, etc).
Comment: (Sean Barker 07-10-03)
Obviated by updates under RBN-1

Closed issue Issue: RBN-2 by Rob Bodington (07-10-05) minor_technical issue
Resolution: Accept. Status: closed

There should be another reference parameters: task_method. The reference parameters should be shown in the EXPRESS-G model. I.e. showing entity to which they are bound. The = in the path need white space E.g. Task_method %^task_method = Task_method% Task_method.name = '/IGNORE' Task_method_version %^task_method_version = Task_method_version% Figure 4 has a larger font than the rest Figure 1 has red attributes - these should be linked to a base type like string and hidden.
Comment: (Sean Barker 07-10-05)
Updated as requested except that task_method is not a reference_parameter. It was agreed (Barker,Gylstrom, Vaxjo, November 05) that any reference to a task would be to a task_method_version. The need to reference a Task_method will be fulfilled by using the Representing_task template.
Comment: (Rob Bodington 07-10-15)
You still need to declare task_method as a local reference_parameter to pass it as an argument into /assigning_identification( items= ^task_method, Note - you do not need to declare this as an external parameter in the XML. The first part of the path should be: Task_method %^task_method = Task_method% Task_method.name = '/IGNORE' Task_method.description = '/IGNORE' Task_method.consequence = '/IGNORE' Task_method.purpose = '/IGNORE' -- Identify the Task_method /assigning_identification( items= ^task_method,
Comment: (Rob Bodington 07-10-15)
Updated

Closed issue Issue: RBN-3 by Rob Bodington (08-01-11) minor_technical issue
Resolution: Accept. Status: closed

The default rdl value for Task_ver_class_name is "Version_identification_code", but the usable classes for populating it is "Progression_identification_code". They should both be "Version_identification_code"
Comment: (Sean Barker 08-02-21)
Corrected