RE: [plcs-dex] Issue submission against Referencing

plcs-dex message

This is a fundamental issue for DEX development and capability (re-) use, not specifically just an issue with this capability.

Given that the schema is built from the Express provided through each capability brought into the DEX, there is (IMHO) a direct relationship between capabilities and the schema, albeit that the Express ultimately gets transformed into xml.

My understanding is that the underlying Express must be compilable for 3 reasons;

..there are perhaps other benefits, but this is not really the issue here.

The point is that either each capability subsumes the Express entities (from the modules) to enable the complete representation of the information scoped for the capability, or it lists the capabilities upon which it is dependant (for those entities not present).

The facility for removing certain (out of scope) aspects of the model within a capability allows us to trim the information model to suit the purpose of the capability. However, if that information is required for compilation purposes, the capability (in this case C012) assumes that it is being brought in somewhere else. For DEX4 this is not the case.

My personal opinion, is that either through providing dependant capabilities or providing the correct model withn the capability, a capability should not have any hidden dependencies and should be able to represent the information described within it.

In short it is assumed that each capability has referential integrity.

If not, then in theory I could pick up any capability, but not know if this was sufficient to represent the data described within it, which I really do not think is acceptable.

From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
Sent: 08 March 2006 04:21
To: Tim Turner; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Issue submission against Referencing_task C012

There is an uncertainty about what the EXPRESS for the capability means. I have assumed that it refers to the information that must be populated. If this is not the case, then the usage guidance must be updated and made clear.

From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: 07 March 2006 19:28
To: 'plcs-dex@lists.oasis-open.org'
Subject: [plcs-dex] 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.

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.

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.

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