This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
RmHome
>
RmMeetings
>
RmMeetings20091005
(05 Oct 2009,
IanGreen
)
(raw view)
---+++ 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 <a target="_blank" href="http://open-services.net/mailman/listinfo/oslc-rm_open-services.net">http://open-services.net/mailman/listinfo/oslc-rm_open-services.net</a>).
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r5
<
r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r5 - 05 Oct 2009 - 18:11:24 -
IanGreen
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback