OSLC CM Technical Discussions Items

Focus is to elaborate on the definition for the ChangeRequest V2 resource and have a list of items (in priority) that I current plan to focus on:

• [Done] properties of type User: creator, owner : how to represent, leveraging FOAF - SteveSpeicher
• [Resolved, incorporate in spec] CmCollectionNeeds Multi-valued properties / Collections representation: what was done in V1 - SteveSpeicher, DaveJohnson, AndreWeinand
  • relatedChangeRequests spec (usage of collection vs. multli-valued property) define a reusable pattern for other properties that typically hold >1 links to other resources
  • need to handle many, many entries in the collection
• [In progress] contextual linking (project level). How to establish that link that one service "manages" or "testedBy" another service - SteveSpeicher
  • Need to understand how to extend to handle yet-to-be-defined links
• [Work with core, include into CM] CmResourceShapeNeeds schema needs for resource creation
  • need for labels for elements (with I18N? support)
• [In progress] CmResourceEvolutionToV2 Evolution of change request definition with new properties and remain backwards compatible - SteveSpeicher
  • mapping of V1 to V2 features, what's new and how things progress - SteveSpeicher
• additional properties are strong candidates for other common/core spec (cross-topic):
  • [Done] tagging - DenisTyrell, SteveSpeicher
    • present as a multi-valued (repeating dc:subject items instead of comma-separated list)
    • [Deferred] a generic (repo-centric) tagging service, to learn the existing tags and frequencies
  • [In progress] attachments - SteveSpeicher
    • only has a single container (or property) for attachments
    • ensure that attachments are both internal or external to service provider
    • maximum size limitations
  • [Done]CmComments - RobertElves
    • possibly leveraging collections
    • caching concerns, if adding a comment would this change the etag for the entire change request resource
    • may need to not be completely flat, support threaded as we
  • [Done] projects
    • simply defined as a common property with an open (undefined) type, discoverable by associated resource shape
  • [Done] priority, severity - valid choices and model
    • simply defined as a common property with an open (undefined) type, discoverable by associated resource shape
• [In progress] state transitions: CmStatesAndTransitions - AndreWeinand
• [Resolved, core shape definition to include] how to fetch dynamic choice lists (tags, priorities, owners, ...) - SteveSpeicher
  • requested to add URI for fetching choice to resource shape definition.
• [Open] fixed contextual based filters (all change request associated with a test case that are open)
• [Open] identification of delegated UIs purpose (create defect, create plan item, create requirement change request, etc)

References:

• CmResourceDefinitionsV2
• CmMeetings

Meetings

28-Apr-2010

See CmMeetings05282010?

21-Apr-2010

Attendees: SteveSpeicher, AndreWeinand, YongLi, MatsGothe RobertElves

Regrets: DaveJohnson, SamitMetha?

• Reviewed Tagging proposal, YongLi to incorporate feedback. Overall team agrees with simple dc:subject approach but want a way to extend to Tag Resource
• Discussed updates to CmComments, RobertElves completed actions. SteveSpeicher to pull into CmSpecV2Draft? after discussion with core
• Agreed to change link type of "manages" to be "managesRequirement"
• Discussed version compatibility scenarios, no updates to existing scenarios

14-Apr-2010

See CmMeetings04142010

7-Apr-2010

Attendees: SteveSpeicher, AndreWeinand, RobertElves, DaveSteiberg? , DaveJohnson, SamitMetha? , YongLi,

24-Mar-2010

Attendees: SteveSpeicher, DenisTyrell, RobertElves, MatsGothe, SamitMehta, YongLi, DaveJohnson

Regrets: AndreWeinand, ScottBosworth, MikKersten

• Service discovery capability
• Gather requirements and scenarios for version extensibility
• Versioning and upgrade concerns 2 major areas:
  • Service discovery: how to evolve to adapt to extended definitions: resource shape
  • Change Request URI: how to retrieve 1.0 vs. 2.0 content, or is 2.0 properties just added to a 1.0 resource definition
    • Look at Atom extension model, where unknown elements are ignorred.

17-Mar-2010

Attendees see CmMeetings03172010

• Reviewed feedback on usage of foaf:Person. Attendees agreed to use the simplest thing that would work is foaf:Person. Awaiting feedback on latest comments.
• SteveSpeicher Working with core on alignment of collection needs and schema
• AndreWeinand is continuing to evolve work on state and transition, incorporating feedback from last weeks review
• other assignments and status is tracked on priorities page

10-Mar-2010

Attendees: SteveSpeicher, SamitMehta, AndreWeinand, DenisTyrell, SofiaYeung, MarceloPaternostro, MatsGothe, RobertElves

• AndreWeinand reviewed CmStatesAndTransitions, Andre received feedback and will incorporate
  Overall team agreed and liked approach, keeping state groups simple
• DenisTyrell briefly reviewed Tagging
• RobertElves briefly reviewed CmComments

24-Feb-2010

Attendees: SteveSpeicher, DenisTyrell, SamitMehta, SamLee, AndreWeinand, RobertElves, DaveJohnson, YongLi, MatsGothe

• Alignment with OslcCore spec
• Reviewed areas with needs across the different specs
• Assigned owners to many different areas (discussions points captured above)

17-Feb-2010

Attendees see CmMeetings02032010

• Defered review on CmCollectionNeeds, working with other topic leads and common concepts to find a uniform approac.
• Reviewed detailed scenario at CmResourceShapeNeeds

10-Feb-2010

3-Feb-2010

Attendees see CmMeetings02032010

• Reviewed proposal in CmCollectionNeeds
• General feedback on the proposal
  • Approach seems to be aligned with REST but not RDF, easily fixed
  • Seems to be fairly complicated

27-Jan-2010

Attendees: AndreWeinand, DaveJohnson, RobertElves, SteveSpeicher, SamitMehta, YongLi, MatsGothe, SamLee, SusanDuncan

• Reviewed CmCollectionNeeds

20-Jan-2010

Attendees see: CmMeetings01202010

• Reviewed usage of FOAF:Person, seems to work fine if: we can subset and extend
  • Needed properties: first and last name, account id, email address
  • Optional: phone #, web url, language
• Reviewed reprioritized list -- agreement
• Assigned ownership, will work on multi-valued properties at next meeting 27-Jan-2010

13-Jan-2010

• Reviewed and agreed on prioritization listed on technical issues/topics to address and approach
• Discussion on User type for properties like dc:creator and oslc_cm:owner
  • See CmResourceDefinitionsV2 for updates
• Discussion on multi-values and collections, collecting issues
  • efficiently handing updating large collections: removal of item, adding of item, etc