RE: Re[2]: SEDS on ISO 10303-1262

["Phil Spiby" <Phil.Spiby@Eurostep.com>]

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
> 
> >   
> 
>