Date: 30 April 2010

Agenda:

• 1. Let everyone know about the AMC review
• 2. Nick to provide feedback on the prototyping effort
• 3. Discuss contents from Nick's email to the mailing list.
• 4. Continue flushing out the Resource Definitions (and RTC/Build Forge mappings): Added updates/notes to the spreadsheet.

Minutes:

Attendance; Pete Birk (IBM), Nick Edgar (IBM), Scott Fairbrother (IBM), Paul McMahan? (IBM), John Nason (IBM)

Regrets:

1. Let everyone know about the AMC review

Nick or Dave will include the detailed minutes for the AMC review meeting.

Some surprised to see we don't spell out verbs, post/put/delete, what services?

We've been assuming it's only currently a readonly API, but we need to change tags, report test results..

Useful to have sequence diagram..

How event notifications would work? OSLC does not have events well-defined.

Some points about planning, schedules, tags (representations of them)...

Exact representation of contributions and how we link to the content.

2. Nick to provide feedback on the prototyping effort

Effort going pretty well... Good fraction of what is spec'd out implemented. Working on collection of results for plan. Approach taking for contributions needs some work.

Fold in recommendations from the core-spec. Updated shared spreadsheet with examples based on some decisions making in pro

Getting services document..

List automation plans for given context, i.e., project area in RTC.

Can get automation plan from individual plan.,

Can get individual result.

Can list artifacts and contributions for a result.

Missing creation of things.

What representations to use for cetain attributes (dates, enums, etc.)

Sub-collections and queries, should adopt core spec to treat uniformly.

Approach to paging as well.

Deliberately ignoring authentication.

XML resource representation hardcoding some OSLC-CM namespacing.

Work items impl contains non-OSLC properties (RDF, OSLC, OSLC-CM, C/ALM, RTC).

3. Discuss contents from Nick's email to the mailing list.

How to support contributions of different type. Want to support logs/downloads/compilation results/static analysis results.. These will have different representations. How to describe in the spec. Different types of contributions..

Well-known types plus an open ended custom type? customType:

SCM spec has a similar issue.. Versionable with subtypes for file/folder/symbolic link..

Need to nail down the feedback from the AMC..

4. Continue flushing out the Resource Definitions (and RTC/Build Forge mappings): Added updates/notes to the spreadsheet..

Question about key vs. url vs. identifier vs. title. Would like clarification on why all of these are needed. Title could be the short human readable label instead of key. URL can be a unique identifier instead of key. Can still keep identifier as a UUID type internal unique identifier.

Should we punt on dependent and parent automation plans? We can still do multiple steps in a single automation plan and have multiple contributions.

Need to come up with a well-defined set of state and verdict attributes so there's no confusion about how to act on them.

Adding "dc:created" attribute for the exact time the automation result was created. Some implementations queue items prior to execution so this can track the difference.

AutomationContribution? needs some work..

AutomationNotification? , would be nice to do this consistently with the rest of the OSLC specs. Nice if the recommendations for notificatoins aligned with recommentations for query collections.. There are well-defined ways to issue queries for which items to filter out of a collection and which properties to include in a result, nice to do the same type of thing when subscribing to events. I care about changes that satisfy these criteria and express the same way as we do in query collections.