[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. ********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]