[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Re[2]: SEDS on ISO 10303-1262
Lothar, I am looking at v1.21, i.e. the one moved back from fixed_modules (where I was making the changes). Notes attribute and Advisory_task_step were both removed. The Advisory_task_step was basically just a classification of a task_step, it adds no further attributes or constraints. The approach adopted here is that we use a task_step and classify it as "Advisory". When looking into the design rationale for the advisory_task_step, it was mainly going to be used to support health and safety tasks associated with task elements, for example "Beware of hot exhausts" etc. However, after discussions with a number of people it was agreed that simple task_steps may not always be sufficient for example "NOTE: if windscreen shattered then remove large pieces with gloves then vacuum fragments before proceeding" (taken from one of my car maintenance manuals). This type of advisory tasks are in fact structural and cannot be managed using the simple advisory task step from the previous version. The approach used now is that task_element can be classified as "Advisory" and this allows use of task_steps (as before) and also allows structured task elements also to provide support for more complex advisory notices. The link between a task element and any associated advisory task elements (as originally provided by the notes attribute) is supported by using the task_element_relationship which itself is classified as "Notes". I was not proposing that the task_element_relationship be used to model concepts from the structured task element. I agree with you that this would cause confusion and should be avoided at all costs, but trying to restrict this in EXPRESS is not possible, the only thing we can do is state that task_element_relationship is not to be used to create relationships which are explicitly supported by the structured_task_element subtypes. Phil > -----Original Message----- > From: Lothar Klein [mailto:lothar.klein@lksoft.com] > Sent: 15 June 2006 12:00 > To: Phil Spiby > Cc: Eva.Miliuniene@lksoft.lt; giedrius.liutkus@lksoft.lt; > plcs-dex@lists.oasis-open.org; kolakows@mantech-wva.com; > keith.a.hunten@lmco.com > Subject: Re[2]: SEDS on ISO 10303-1262 > > > Phil, > > Thanks for your feedback. > I'm sorry not to have added you to the email list. I looked > who worked on the arm.exp file and notified them. It seems > you worked on the other files and I didn't check them. > > The published version, based on > /stepmod/data/modules/task_specification/arm.exp v 1.20 had > the notes attribute. > > Looking to your argumentation I see more issues against this > module. It is dangerous to have Task_element_relationship to > relate task_elements for cases similar to the ones of > Structured_task_element subtypes. The standard should clearly > disable this (and from the mapping there would be no way to > distinguish anyway). > > Somehow Advisory_task_step vanished - any idea where it is? > > Your proposal on the new where-rule to write (2) looks good. > > Lothar > > -- > // Lothar Klein, LKSoftWare GmbH > // Steinweg 1, 36093 Kuenzell, Germany > // +49 661 933933-0, Fax: -2 > // mailto:lothar.klein@lksoft.com http://www.lksoft.com > > Thursday, June 15, 2006, 11:28:26 AM, you wrote: > > > > > > Lothar, > > > > > > > > It would have been nice if you had included me on the distribution > > list since I am responsible for splitting this module! > > > > This could easily have been found out by looking either at > the file > > headers or on the sourceforge logs to see who had worked on the > > module. > > > > > > > > With respect to your comments: > > > > > > > > 1) Wrong way around! The Notes attribute (and advisory_task_step > > entity) were removed from the following: > > > > arm.exp, arm.xml & arm_descriptions.xml. > > > > The mapping information still contains this attribute, > and needs > > to be fixed. > > > > > > > > The rational for this change was that as it stood > there were two > > ways of adding advisory task steps to a task element, one > through the > > notes attribute, the other through task_element_relationship. From > > the context of supporting Function Based Behaviour the > preferred route > > was to remove the notes attribute. The approach of using the > > task_element_relationship also allows structured advisory task > > elements to be used. To support this fully we probably need to add > > some standard classes to the task_specification module, such as > > "Notes" on the task_element_relationship, and "Advisory > task elements" > > on task_element. > > > > > > > > These changes were discussed at length with Nigel Shaw and Sean > > Barker before being made and posted in the fixed_modules > area. I was > > hoping for wider review of the changes before they were > brought back > > into the main STEPmod area, but someone decided that the > fixed_modules > > area should be moved back as one. > > > > > > > > 2) I agree with your point here. I do not know of any FFBD tool or > > UML tool which would allow the same function or activity > to be used > > in multiple places. Though I think the rule could be > better written > > to ensure that we don't have similar problems with > > extended_task_element. > > > > What about: > > > > SIZEOF(QUERY(u <* USEDIN(SELF,'') Š > 'TASK_ELEMENT_ARM.TASK_ELEMENT' > > IN TYPEOF(u))) <= 1 > > > > > > > > 3) I am not sure about the need to include the series concept into > > task_element. > > > > > > > > 4) I have not considered the mapping yet, and will have to look at > > this whilst considering the extended_task_element module. > > > > > > > > 5) Seems reasonable. > > > > > > > > Phil > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]