Agenda 20 March
- Updates on participation
- New issues (see here)
- Status
- Scenario development: Requirement Hierarchy.
Attendees
Ian, Steve, Mike, Jim, Yuri, Gabriel, Clyde
Apologies: Dominic
Minutes
Introduced two new members, Yuri and Gabriel
Jim: is there a single canonical hierarchy or is hierarchy just a view. What are the properties of containership? Eg cascaded delete?
Clyde: inheritance of attribute values
Jim: is there some study of container properties?
Ian: Describes DOORS modules. Jim: what are the semantics? eg timestamps, etags, inheritance of property values (eg change datatype of a parameter in an operation, likely want to rev the operation, and perhaps the operation). What happens to module etag when requirement is changed in that module.
We should do this for RM, and also AM and QM. Build a scenario that requires hierarchy in RM with AM and QM. Then what happens with AM and Qm. Can we do this first without hierarchy?
Ian: start a section with simple scenario with RM, AM, QM resources. What happens in this model when changes arise?
Steve: w3c ldp on containers. tbl wanted to nuke the things in the container - composition not aggregation. but later, ldp has two types of container - composition and aggregation. More recent idea is “recursive delete”. Jim: urghh! Client needs to make the choice. Semantics could be given by properties on the container, or characteristics of the membership predicate, or properties on the contained resources. Jim: can’t leave the onus on the client, since it doesn’t know enough.
