Agenda

• Outsdanding Action items:
  • Feedback from JimConallen is oslc.properties being REQUIRED is acceptable to his implementation effort. (Now closed.)
  • IanGreen has completed the RDFS vocabulary and shared this with the community. Recommendation to publish this to open-services.net.
  • IanGreen continued soliciting IP covenant declarations.
• Agree that RDFS vocabulary is ready to publish (see RmSpecificationVocabularyV2)?
• Requirements Organization discussion
  • I'd like us to review Andy's document. In it he makes some assertions - for eample, that a requirement should reference the folder which contains it (should a requirement change when it is moved to another folder?) Should we deal with requirement ordering? For example, how would a Report (via OSLC Reporting) over a specification be possible?

Attendees: IanGreen, SteveSpeicher, DaveJohnson, DominicTulley, SimonWills

Apologies: ScottBosworth, AndyBerner

Steve: Change to XSL should be shared back to core. Preference is for consistency across the CORE. Ian can suggest/propoe a change on the core mailing list.

Ian - could we refactor the spec but we can do that later.

Dominic: typo. in specifiedBy specification. needs to be reviewed. Action on Ian to make sure this happens.

Simon: how do we deal with application scenarios in which clients want to do "more" than basic clients.

Dominic - we can use existing types to capture heading/requirement distinction

Dave - we talked about more than one hierarchy - the section/subsection, or do we need just groupings of a single type? Simon: people use headings in a variety of ways. It is not easy to anticipate how users are going to use these capabilities? We have two distinct things - tree of things and things. Links alone don't give orderedness. There are more degrees of freedom that we need - (trees not graphs).

Simon: hierarchy is resource type agnostic. Folder is just another kind of ordered hierarchy. Hierarchy resource can be composed.

Action on Ian to refine the straw man proposal.