Agenda

Meeting 5th October 2009 (3PM UTC)

• Specification progress
  • Performance concerns (Matt)
• • Delegated Creation UI: added
  • Requirement Factory: added.
    • Requirement Factory: Discuss use of RM service document hierarchy as a way of creating requirements in a known place. Systems organise requirements differently (for example, RRC puts them in folders, DOORS into a module). How can we deal with this when we want to programmatically create requirements using a factory? I propose to use the service document to do this. I'd like to discuss and move this forward.
  • Review all OPEN and UPDATED issues in the register and attempt to CLOSE them.

Minutes

Apologies: AndyBerner, GeorgeDeCandio

Attendees: IanGreen, SteveAbrams, DominicTulley, ScottBosworth, PaulMcMahan, JimConallen, MatthewStone, DavidRuiz, SimonWills, DevangParikh,TorgeKummerow

Matt on performance concerns. Previous experience in fetching large DOORS modules. Concern over fine-grained access to requirements from collections. Large numbers of GETs. Also, problem of large (by volume) "primary text". OSLC RM could adopt "paging" to allow large aggregations to be managed. Do we need inline representations of requirements in collections? Is paging across a collection required in the specification? Don't think that large numbers of links likely. Possible to defer until post 1.0? Do we want query in the spec? Do we want pagination on collection resource? There was consensus that we would likely need paginatioin at some point but that the need for it in 1.0 was not obvious. Matt and Ian to look at this and report.

Ian outlined one way in which the existing tree of service documents could be used to convey context information for programmatic requirement creation. This received mixed responses and we did not get to the bottom of this. In particular Steve observed that perhaps the granularity of contexts offered by service discovery should be uniform across the domains, and that Ian's proposal was counter to this.

Devang and Jim suggested an alternative means of describing the contextual information (a property on the requirement resource). Ian was resistant to this. More work required to resolve this issue.

Meeting concluded without time for review comment walk-through. That discussion will be taken to the OSLC RM mailing list (to subscribe, please visit the http://open-services.net/mailman/listinfo/oslc-rm_open-services.net).