OSLC Core Meeting December 15, 2010

Last week's meeting

Link to OSLC Core spec: OslcCoreSpecification

Meeting logistics

How to dial-in to our telecon and login to our screen-sharing session (when we need it).

Telecon Info

• USA Toll-Free: 888-426-6840
• USA Caller Paid: 215-861-6239
• Participant Code: 6867265

• Other numbers:
  • https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6867265&accessNumber=2158616239

Online meeting

(when we need it)

• For IBM employees, use the following link:
  • https://lli.ibm.com/meeting/join/?schedid=4446009 (IBM intranet authentication required)
• For people outside IBM, use the following link:
  • https://apps.lotuslive.com/meetings/join?id=4446009

Agenda

• OSLC Primer plans

• Dave's first suggestion was overview + primer

• Arthur's feedback: too many generalities
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-December/000653.html
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-December/000666.html

• Steve's suggestions: multiple docs needed
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-December/000652.html

• Jim's outline
  • http://open-services.net/pipermail/oslc-core_open-services.net/2010-December/000682.html

• Dave's new outline
  • http://open-services.net/bin/view/Main/OslcPrimer

• Primer issues
  • Using the OSLC RI seems like a good idea and makes it easier for us to write the primer and for folks to learn via experience with a functioning system. But...
    • How much OSLC RI setup and getting started information needs to be in the OSLC Primer?
    • How dependent do we want the document to be on an OSLC RI?
  • Do we stick to HTTP and representations, or should we show client code in Java and other languages?
  • How should authentication be handled in the primer? HTTP Basic Auth is easy to explain, but, OAuth client is not so easy.

• Are we ready to be final?
  • Still have open issues and we need one more domain to become final

• Special meeting this week to discuss query syntax issues
  • Thursday 3:3PM US/ET - using our usual telecon number
  • See Finalization issues 9-21
  • So far: Steve Speicher, Scott Bosworth, Arthur Ryman, Nick Crossly and Tack Tong

• Meetings cancelled for next 2 weeks
  • Happy holidays!

Minutes

Attendees and notes from the meeting

Attendees

• DaveJohnson
• JimConallen
• NickCrossley
• SteveSpeicher
• IanGreen
• ArthurRyman

Topics discussed

We went through the agenda items above. Here are my notes:

Arthur R:

Consumers vs. implementors: most people will be implementing consumers

Need a scenario and introduce features progressively

With screenshots too

Realistic task, build it up end-to-end

e.g. impact analysis example

Jim C

Impact analysis might not be a web app, an Eclipse client might be more appropriate

SORI is a web app, but it is very bare bones

Screenshots are a good idea too

Arthur R

Don't like idea of Eclipse client, we should focus on web, HTML, Javascript

Jim C

Web client requires too much framework code, Dojo, etc.

Dave J

Can't we keep things simple, e.g. just simple JSP pages

Bare bones UI, as you have done so well in SORI

Using Eclipse also brings in framework code too, a lot of it

Dave J

How dependent on RI

Arthur R

Document should be self contained

Only place we need UI is delegated UI, preview

Show raw RDF, also screenshots

Steve S

Agree

Jim C

Reference and have as separate document on how to use OSLC RI

To run the primer exercise

Dave J

What about authentication

Steve S

Do a separate primer for OAuth

Arthur R

Point them to existing primer

Ian & Nick

OAuth should be covered

Jim C

Separate "How to Integrate with Rational projects"

Nick C

OK to have separate document, but need to cover it

Steve S

Good to have definite scenario to build up

Dave J

Arthur suggested that and specifically impact analysis

Steve S

How about linking defect to test case

Dave J

Need some scenarios

Arthur R

This (Dave's outline) is a check list of things we want not a TOC

The TOC will become apparent when we have a scenario

Start simple, build up scenario. Bring

Dave J

I like having a starting section that explains basic operations

Arthur R

Primer should be induction rather than deduction

Start with scenario, not basic operations

Jim C

That will make it more difficult to follow along with RI

Because resource URIs will be different

Steve S

But we can pre-populate RI with data

Jim C

Agree, but again primer won't depend on RI

Authors

Steve S, Jim C and Dave J

Arthur R interested in review

Steve and Dave

Let's do it on the wiki

AI: Dave Add Jim C to Query Syntax meeting