OSLC Core Meeting March 23, 2011

Previous meeting

Link to OSLC Core spec: OslcCoreSpecification

Meeting logistics

How to dial-in to our telecon and login to our screen-sharing session.

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

Item: POST by Query

Item: Community news

• Progress in OSLC Tools
• Progress on OSLC Primer
• Other community news?

Item: Change Log

http://open-services.net/bin/view/Main/IndexingProposals

Issue summary

• Move Change Log specification to wiki format
• Move issues to OSLC "issues" format
• Allow request to specify date range - consensus: not yet
• Order of if events is important - consensus: yes
• Use dc:date instead of oslc:at - consensus: yes
• Use normal OSLC paging technique - consensus: yes

• Is CLM an OSLC term
• Don't define indexable resources
• Allow Change Events to be resources?
• More general term for Indexing Profile?
• Names for oslc:create, oslc:update and oslc:delete
• If we have order, do we need date?

Minutes

Attendees and notes from the meeting

Attendees

Attended:

• Steve Speicher
• Frank Budinsky
• Jim des Rivieres
• Dave Steinberg
• Marcelo Paternostro
• Arthur Ryman
• Mike Leoffler
• Ian Green
• John Arwe
• Bill Higgins

Regrets:

• Jim Conallen
• Nick Crossley

Topics discussed

AI: Dave and Frank: get proposal into Wiki format

AI: Dave and Frank: get issues into standard issue format

Frank review issues on Indexing Proposal page

Item #1: collaborative lifecycle management is an OK term to use, CLM acronym unnecessary

Item #2: Indexable Resource, need way to mark pages as indexable

• Arthur: HTML pages are not marked like so, but there is a robots.txt file that guides search engines
• Arthur: Have we designed extensions to Service docs to enable indexing
• Frank: We have the notion of a Indexing Profile (need new name), we ask for:
  • One or more query capability
  • One change log for those capabilities
• Jim: this ties the indexing profile, change log etc. to a full-blown OSLC provider, can we decouple?
• Frank: seems like a good idea, way to take service provider, register self as listener on service provider
• Jim: protocol must support needs of indexer, not just be a simple observer. Needs to enumerate everything, all resources
• Arthur: standards orgs start with a set of requirements for a spec, need to state use cases, then verify that spec meets use case requirements
• Arthur: this is really a notification spec
• Ian: how far can we take this decoupling? different providers might have resources in different security contexts.
• Jim: make it so implementing indexing has very low barrier to entry
• Dave: do we state what should happen if you do get on a query base URI with no query string at all?
• Arthur: yes, you get back everything, or redirect to first page of everything
• Arthur: if we decouple from query, then we need to re-invent it
• Jim: we really need to take this opportunity to decouple, we can couple to format?
• Jim: could be good to have single URL for change log, and then way to get all resources in world
• Arthur: not all, but all in scope of change log
• Jim: yes

Frank: we need to have a follow-up next week

AI: Dave to get meeting on schedule

Item #3: Name for Indexing Profile?

• Ian: Change Log profile
• Arthur: Notification profile
• Jim: those names do not mention need for enumerating all resources in scope
• Jim: something that enumerates all resources is not change log design center
• AI: Frank will start email thread on this, we need better name here

Item #4: Namespace

• Consensus is that Change Log should be in separate namespace from Core
• Frank: leaving this open for now

Item #5: Naming for change events

• Frank: are we OK with Creation, Deletion, Update, etc. since we will have our own namespace
• Consensus is: OK
• Jim: is there value in enumerating those values?
• Frank: the value of Deletion is obvious, need it to keep index up to date
• Frank: Creation and Modification are tricky, and are both essentially the same to use
• Frank: Yes, there is value or at least no harm in Create / Update distinction