OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-dex message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: SEDS on ISO 10303-1262


Title: Message
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]