RE: [plcs-dex] View on Complex types?

["Nigel Shaw" <nigel.shaw@eurostep.com>]

Title: Message

While you are quite right to note that the possibility has not been constrained out, we should not encourage the creation of complex instances of Activity_method.

 

The principle reason why all are subtypes of Activity_method was driven by the need to be able to map to the AIM. A second driver was to work around the base model where any activity SHALL have one and one only activity method. This does not reflect reality where there may be multiple "methods" applicable to a given activity.

 

Yes, we should document a recommendation that such complex types are not to be used. (Although I would not rule out their usage to meet requirements that combine task and schedule - such as occur in some systems engineering formalisms. In my opinion, they are not needed to match classical ILS requirements.)

 

To answer you question on Activity_method as abstract supertype - No because of the use of Activity_actual to record history where the activity_method is only being defined to enable description of what happened rather than as a recipe to be followed again later. (Another consequence of the 1:1 between Activity and Activity_method.)

 

    Nigel 

-----Original Message-----
From: Tim Turner [mailto:tjt@lsc.co.uk]
Sent: 16 January 2006 07:38
To: 'Plcs-Dex teams (E-mail) ' (plcs-dex@lists.oasis-open.org)
Subject: [plcs-dex] View on Complex types?

Dear All,

I have been looking around the task, activity and scheme models for a few days and have some comments & queries in this and subsequent emails which I could do with some clarification.

First off, there are not many complex types in AP239, nor are any advocated for use (as far as I'm aware at present) in any of the Dexs. However, this area of the model has several opportunities to create complex entities for many of the subtypes of activity_method. For example, Scheme, Scheme_entry and Scheme_version can/could all be complexed with one of Task_method, Task_element or Task_method_version. I can see that there might be advantages to using complex types when trying to represent both a scheme_entry and a task_method, but applying reference data to this would seem to create more problems than it would solve.

Hence my first question: Is it accepted that in PLCS/Oasis, we will not be creating ANY complex types? Second up; if so, is this written down anywhere (I could not find it)? If not it should be for others (e.g. in the help section?).

The other main areas where the model allows complex types is in the subtypes of product_view_definition and view_definition_usage which deal with product structure.

Kind regards,
Tim

NB - Here's some of the Express-G for activity_method.
Would activity_method best be treated as an ABS?

<<...OLE_Obj...>>

*************************************************************************
*
* Mr. Timothy J. Turner BSC(Hons) MSc, MBCS
* Executive Consultant, Enterprise Integration Technologies
* 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-7885-393225
* e-mail: tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> Internet: <http://www.lsc.co.uk/>
*
*************************************************************************
<<Tim Turner (Tim Turner).vcf>>

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