This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
OslcCore
>
OslcCoreMeetings
>
OslcCoreMeeting20101215
(23 Aug 2011,
SteveSpeicher
)
(raw view)
---+ OSLC Core Meeting December 15, 2010 [[OslcCoreMeeting20101208][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 [[http://open-services.net/bin/view/Main/OslcCoreV2Issues#Finalization_issues][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
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r5
<
r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r5 - 23 Aug 2011 - 13:36:34 -
SteveSpeicher
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback