Date: Wednesday, 6 January 2010

Time: 12:00 PM Eastern, 9:00 AM Pacific, 6:00 PM Zurich
(contact SteveSpeicher if you'd like to participate)

Agenda:

• Call for last minute agenda changes
• Update on outstanding Actions see CmMeetingsActions
• Review specification needs for CmOfRequirements
• Review specification needs for CmScenarioReviews
• 2.0 Roadmap review (dates and scenarios)
• Review of CmResourceDefinitionsV2
  • Review any updates since last meeting
  • Discussion around need to carefully define Project and Component: suggestions were around defining them in generic terms as "context" (Project) and "subtext" (Component) for hierarchal systems, though there may be a need for tagged-based model (Google code).
• Progress on 2.0 specs
  • Prioritize scenarios
  • Define scope - CmArchitecturalDirectionV2
  • Milestone plans
  • Progress on extending participation - both as WG participants and implementations
• 1.0 spec maintenance items
  • Feedback from implementations CmImplementationReports
  • CmSpecificationIssueTracking
• Next meeting: 20-January-2010

Minutes:

Attendees: SteveSpeicher, AndreWeinand, MikKersten, RobertElves, DenisTyrell, MarkRinger, SusanDuncan, IanGreen, YongLi, SamLee, SamitMehta

Regrets: ScottBosworth, MatsGothe

• Call for last minute agenda changes
• Update on CmMeetingsActions (see following)
• No updates since last meeting on CmOfRequirements or CmScenarioReviews (schedule for Jan 20th meeting)
• Review of roadmaps targetting of finalization by May 2010 and convergence starting as early as March, looks good to most. Confirm at Jan-20th meeting
• Review of CmResourceDefinitionsV2
  • Review proposed changes and outstanding items listed V2 resource definition
  • Looking for owners to drive specification for V2 resource definition (see reference for areas)
  • ACTION: SteveSpeicher Need to add links/properties for requirements and test cases
  • Discussion on modifying and reading status property (how to determine if CR is done, how to update it to be done and how to handle additional states)
    • Perhaps add concept of actions/operations to CR to modify the status instead of PUTing status field directly and infering action.
    • Gather requirements for states and state transitions: possibly have in a schema/service descriptor for peforming state transitions.
    • RTC uses two attributes to define completeness of CR: status and resolution, but falls into state groups for things like open, in progress and closed
    • States/statuses can be complex constructs that have the standard OSLC element, along with provider-specific and other info: label, valid operations, etc.
• WG agreed to move to weekly meetings to accellerate progress on 2.0 specs
  • ACTION SteveSpeicher to schedule out additional meetings with specific technical topics on the agenda
• Next meeting 20-Jan-2010