Reporting Meeting, 2009-12-07

See Reporting Meetings for meeting logistics.

Agenda and Minutes

Agenda

1. Call for last minute agenda changes
2. Update on outstanding actions
3. Service Discovery - SebRose
4. REST API - DragosCojocari
5. Reference Implementation discussion
6. Data Warehouse specifics

• record deletion in data warehouse loading
• delta load of changed records

Outstanding Action Items

• Action Item: PaulMcMahan and BenjaminWilliams to draft a use case on instance-based variable schema from reporting perspective.
• Action Item: TackTong and DragosCojocari to address the new use case based on RSx in spec. Note: Will be done later.
• Action item: SebRose will work out an example on how RM service discovery would work in the context of reporting for next week discussion.
  • Done.
• Action item: PaulMcMahan will work out an example on how QM service discovery would work in the context of reporting for next week discussion.

Minutes

Attendees: PaulMcMahan, DragosCojocari, JamesMoody, ScottBosworth, XiangDongHu, SteveSpeicher, BenjaminWilliam? s, ArthurRyman

Regrets: SebRose, StevePitschke

1. Service Discovery - SebRose: discussion moves to next week

2, REST API - DragosCojocari: discussion moves to next week

3. Reference Implementation: The following will do implementation to support validating the specification. Will get back to kick off this in Jan. 2010.

• Reporting Client as consumer : Rational Insight, Rational Publishing Engine
• Service Provider : Raitonal Team Concert, OSLC - Software Estimation

4. Deletion : Options considered

1. soft delete with an indicator marking record as logically deleted.
2. add a REST API to get all deleted records since a date-time.
3. reporting client to request individual records one at a time to validate existence.
4. reporting cleint query to get resource URL (or an unique identifier if exist) for all current records (excluding hard and soft deleted). It would be reporting client's responsibility to map work what has been deleted in its data repository.

Option 4 is chosen for

• no new REST API needed
• performance

Note: Service Provider should be aware of this use case and optimize if feasible.

5. Delta loading for changed records: This will be achieved using query on dc:modified. This means that all OSLC resources will need to have dc:modified as a property for participating in delta load. So far, most OSLC resources defined have dc:modified as a property.

6. QM Service Discovery :

• A service discovery document may cover services for one or more resources.
• Some domains like QM may have one single service description document covering all QM resources while some domains like RM may have many service description documents with each one covers one RM resource.
• There will be only one "schema" service for all resources.
• Will have a separate service entry for query each resource, though it may be the same for as the collection service URL.
• Merge content of reporting service document into the resource service document.

Action item: PaulMcMahan will rework a merged service description document for QM.

Next week

• Service Discovery - SebRose
• REST API - DragosCojocari

Comments

Add your comments here: