RE: [plcs-dex] RE: STATE OBSERVED Capability

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

Title: Message

The question is not whether to use state_observed to record approval.

 

The problem is that Task has a life cycle - this is needed to meet the requirements of DEX 3.

 

A life cycle is effectively a fine state machine. The life cycle for Task has four states and three transition. These transitions are approvals.

 

In the real world, we can assert a life cycle state by asserting its current state (state_observed), or equivalently, the last state transition (approval).

 

The question originally posed concerned the State_observed capability. As written, it does not support the asserting of life cycle state through approval. The question was therefore a) can life state be asserted by approval, and b) if so, where should such a capability be documented?

 

......

 

In Task life cycle, approval of the Task is assertion of a state-transition, for the purpose of defining the changeability of data (i.e. what does it mean if the Task data you send me does not match the Task data I have already?). This is quite distinct from the approval of Task as being a suitable description of how to do something on a product, which is done by approving Task_assignment.

 

.......

 

It is considerably easier to understand a complex life cycle through its state transition diagram than through a set of rewrite rules for trace generation. It is also much easier to simply read the state from a state-variable than deduce it from the trace of state transitions. Further, requiring that elaboration of the life cycle is done by sub-typing states means that any life cycle can be simplified back to the root life cycle. This ensures that there is always a base life cycle in common between any two PLCS implementations. Writing such a constraint on rewrite rules would be opaque.

 

The proposal to base Task life cycle on a state transition diagram - and therefore require state assertion by approval - should be taken in this context.

 

..........

 

Pull chain here: John - There is no such entity as Task_specification, the entity is Task, which is a subtype of Activity_method, which is not to be confused with task, which, according to the definition, is not what Task models.

 

 

Sean Barker
ATC Filton
0117 302 8184

-----Original Message-----
From: Nigel Shaw [mailto:nigel.shaw@eurostep.com]
Sent: 09 June 2004 14:52
To: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE: STATE OBSERVED Capability

My two pence:

 

Approval is not same as state observed.

 

An approval is almost always "for a purpose" although this purpose if often implicit . An Item (such as a task) is approved for use. In this case I would expect the approvals to apply to the assignment of the task to a product as well as the task.

 

A State_observed is a condition of the thing(s) to which it is assigned. It is not "for a purpose", it just exists (or did when it was observed).

 

Hope this helps a bit - I would not see State_observed as a way to handle approval.

 

    Nigel

-----Original Message-----
From: Gordon Robb [mailto:gor@lsc.co.uk]
Sent: 09 June 2004 07:30
To: 'john.dunford@eurostep.com'; 'Barker, Sean (UK)'; PLCS-MODELERS-L@ATICORP.ORG
Cc: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] RE: STATE OBSERVED Capability

John,
Your final para "View from others would be welcomed. Surely we should not use "approval"
as consistently as we can for both product-versions, documents and
task-specifications?" I think requires tuning.
The intent of the PLCS generic definitions is that 'approval' is applied the same to a product (the product can be all that you describe i.e. is the result of a process (ISO 9000:2000 Fundamentals etc))

regards
Gordon

-----Original Message-----
From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
Sent: 08 June 2004 20:03
To: 'Barker, Sean (UK)'; PLCS-MODELERS-L@ATICORP.ORG
Cc: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] RE: STATE OBSERVED Capability

Sean,

Please can you use the oasis list to continue this discussion. PLCS Data
Modellers is closing down.

Re the content, the module definition of task has been accepted by PLCS
after much discussion and a DIS ballot.  I don't see any support for
your trying to change it now. As I said in my last mail, if you want to
talk about a Task specification, you have that term to available.

Regarding approval of task specs you are right to point to two different
situations, both of which are clearly reflected in the PLCS AAM (A2.4.1
and A2.4.2).  As a first step a Task Specification can be approved as a
valid definition of an activity to respond to a support driver
applicable to a product in focus.   This should be done using approval
of the Task Specification/activity method.  Such an approval can be
given without any requirement to assign the task specification to a
detailed product context (i.e. a task assignment), as the task
specification already has a context in terms of the support driver it
addresses.  Approval of the task assignment is a separate issue,
typically linked to the definition of trigger conditions and
potentially, the assignment of a justification. 

I remain of the view that the use of state-Observed to record approval,
should be discouraged except for the limited case where "approved" is
clearly listed (using Ref data) as a state within a set of workflow
stages.  If you're not happy with this, please call.

View from others would be welcomed. Surely we should not use "approval"
as consistently as we can for both product-versions, documents and
task-specifications?

John Dunford,
Eurostep Limited,
25, Chaucer Road, BATH BA2 4QX, UK
Tel: +44 1225 789347
Mobile: +44 0797 491 8202
www.eurostep.com
www.share-a-space.com
 

-----Original Message-----
From: PLCS Team Data Model Group Exploder
[mailto:PLCS-MODELERS-L@ATICORP.ORG] On Behalf Of Barker, Sean (UK)
Sent: 07 June 2004 11:56
To: PLCS-MODELERS-L@ATICORP.ORG
Subject: Re: STATE OBSERVED Capability

I should have picked up Nigel's definition in QA - I know who will have
to fix it if I raise an Issue.

I'm not sure that I want to identify the state of a Task with the
Activity to define it. The work_request/work order which raises the
directed_activity covers only part of the lifecycle - that of defining
the task, and does not cover usage or obsolescence.

The question is, what would an approval mean. In one case an approval of
a task is an approval of its applicability to a particular product,
which is an approval against task_assignment. The lifecycle status is
concerned to say that the definition is stable for use, and is therefore
is only an approval of the state transition in the lifecycle, and would
probably be better recorded against a state. I will therefore  continue
the view that state_observed could be asserted by approval.

Sean Barker
ATC Filton
0117 302 8184

-----Original Message-----
From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
Sent: 06 June 2004 11:29
To: Barker, Sean (UK); PLCS-MODELERS-L@ATICORP.ORG
Subject: RE: STATE OBSERVED Capability

Sean, Before you start pulling my chain on definitions I suggest you
read AP239 viz: 10303-1262 Section 3, Para 3.5.1  You don't need to read
it a 100 times - once should suffice! (task: a possible or intended
activity (editor N.Shaw!!))

In future mails, when you mean task specification, please say task
specification.

Having got the entertainment out of the way, I return to the matter in
hand.  For a completed and agreed task_specification I recommend that
the concept of approval be applied directly to a tsak_specification,
using the approval module (as for a product_version). The use of
state_observed to achieve this should be deprecated.

That said, I can imagine a requirement to track the development of a
task specification through a series of defined states which make up
states in a workflow e.g. not started, started, first draft complete,
ready for review, complete and approved.  When this occurs, the progress
of the task spec development through the workflow state it should be
handled by applying state_definition and state_observed to the activity
of developing the task specification, and NOT by defining states for the
task spec itself.  I think this corresponds (sort of) to your option 4.

I agree that the capability on representing a state_observed should
state explicitly that a corresponding state definition is optional.

John Dunford,
Eurostep Limited,
25, Chaucer Road, BATH BA2 4QX, UK
Tel: +44 1225 789347
Mobile: +44 0797 491 8202
www.eurostep.com
www.share-a-space.com

-----Original Message-----
From: PLCS Team Data Model Group Exploder
[mailto:PLCS-MODELERS-L@ATICORP.ORG] On Behalf Of Barker, Sean (UK)
Sent: 01 June 2004 10:40
To: PLCS-MODELERS-L@ATICORP.ORG
Subject: Re: STATE OBSERVED Capability

John

        before Nigel makes you write it out 100 times, A Task in NOT an
Activity. It is a specification of how to do something, not a
specification that something should be done (or even, has been done).
Therefore its state cannot be observed, only asserted. The implication
is that there is no observer but there is an approval.
        The current representing_state_observed does not cover this
usage. This leaves four possibilities:
1) representing_state_observed is extended to cover this case
2) Task_specification describes this usage
3) We ignore the problem and leave the standard vague
4) Representing_state_observed explicitly rules out this usage

Regarding the additional comments, it may have been intended that a
State_observed can occur without a corresponding state definition, but
it is not written down. To quote the capability "An observed state is
related to the defined state (State_definition), of which it is an
occurrence, by State_assessment and State_assertion", which might be
taken as asserting the opposite.

The problem in writing the capabilities is not merely to write true
things about the standard, but to provide criteria that differentiate
the true from the false (i.e. give a normative interpretation).

Sean Barker
ATC Filton
0117 302 8184

-----Original Message-----
From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
Sent: 01 June 2004 09:58
To: Barker, Sean (UK); PLCS-MODELERS-L@ATICORP.ORG
Subject: RE: STATE OBSERVED Capability

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.

     Keep this in mind if you answer this message.

Sean, It was always intended that the "something" to which a
state_observed applied could include an activity.  Is this what you mean
by "a task"?  If you (the observer) are reporting, based on your
knowledge of the real world, that an activity is complete I don't
personally see any need to fiddle further with the semantics of
"observed" v "asserted".   Similarly, if you are reporting either that
you did approve, or witnessed the approval, of a task_specification the
term "observed" seems close enough to me.

As to your other questions:
1) Yes - we always intended that observed states COULD be independent of
defined states 2 and 3 I'll leave to Rob.

John Dunford,
Eurostep Limited,
25, Chaucer Road, BATH BA2 4QX, UK
Tel: +44 1225 789347
Mobile: +44 0797 491 8202
www.eurostep.com
www.share-a-space.com

-----Original Message-----
From: PLCS Team Data Model Group Exploder
[mailto:PLCS-MODELERS-L@ATICORP.ORG] On Behalf Of Barker, Sean (UK)
Sent: 21 May 2004 11:10
To: PLCS-MODELERS-L@ATICORP.ORG
Subject: STATE OBSERVED Capability

Rob,

As I read it, the current state_observed capability is restricted to
being a state of something, such as a product. I would like to use it to
track the lifecycle of Task. In the case of lifecycle, a Task is in the
given state by assertion (usually by approval), rather than observation.
Should State_observed be updated to cover this case?

Also, I have the following observations:
1) It is ambiguous from the capability whether every state_observed must
be the assertion of some state_definition. Can there be observed states
for which there is no defined state?
2) When applying identification to state, what is the reference data
that ensures the identifier is interpreted as a state_identifier. What
does this state identifier mean?
3) There are currently no part 21 fragments for several of the instance
diagrams - is this intended?

Sean Barker
ATC Filton
0117 302 8184

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
********************************************************************

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
********************************************************************

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.
********************************************************************

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************