Issue submission against Referencing_task C012

[Tim Turner <tjt@lsc.co.uk>]

Title: Issue submission against Referencing_task C012

Refering to tasks in this capability has been described as requiring two things; both a task_method_version and a task_method. This is because the identification and the version information are (when represented) associated to these two entities.

The capability C012 - Referencing_task includes both of these entities. However, within the definitions of these entities are other, optional entities.

E.g. Task_method_version refers to the optional content of type Task_element.

ENTITY Task_method_version
  SUBTYPE OF (Activity_method);
  content : OPTIONAL Task_element;
  of_task_method : Task_method;
END_ENTITY;

Task_element is therefore, required in order to properly compile a schema which allows for task references, even though task_element may not be used (and certainly is not used from the perspective of providing a reference).

However, the capability Referencing_task is deficient in this matter and cannot be used to reference a task without it.

Regards,
Tim

NB - DEX 4 compilation needs to make reference to tasks (but not to represent them - that being a DEX3 remit) & is therefore, dependant upon this capability.

The Task_element entity is copied below for convenience.

ENTITY Task_element
  ABSTRACT SUPERTYPE OF (ONEOF (End_task,
                                Exit_loop,
                                Structured_task_element,
                                Task_element_levels,
                                Task_invocation,
                                Task_step))
  SUBTYPE OF (Activity_method);
  notes : OPTIONAL LIST[1:?] OF Advisory_task_step;
END_ENTITY;

Of course, this then brings in many other entities and the difference between this capability and that for representing_task (C015) becomes more & more less meaningful since both contain the same entities. In fact the same issue is true of representing_task, bringing in to doubt the reason for the existence of these two capabilities, or the current mechanism for referencing is questionable.

One (off-the-cuff) possible solution to address this and other referencing problems like this, where entities are ONLY required for compilation purposes only, is to introduce *stub* entities. These are stubs in the sense that they provide only the entity for the purpose above and have no attributes. E.g. ENTITY Task_element END_ENTITY; - because they are not used to represent any information.

Another alternative is to reconsider how we specify a reference. For example, without having to use all the entities used to define them in the first place.

*************************************************************************
*
* Mr. Timothy J. Turner BSC(Hons) MSc, MBCS
* Executive Consultant, Systems Integration Division
* LSC Group, Lincoln House, Wellington Crescent, Fradley Park, LICHFIELD, Staffordshire WS13 8RZ, ENGLAND
* UK Switchboard: +44-1543 446800 Fax: +44-1543 446900
* Mobile (US) telephone: +1-843-4759179
* Mobile (UK) telephone: +44-7785-393225
* e-mail: tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> Internet: <http://www.lsc.co.uk/>
*
*************************************************************************

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED***   The information in this message is confidential and may be legally privileged. It is intended solely for the addressee.  Access to this message by anyone else is unauthorised.  If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful.  Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG