OSLC Core Meeting June 29, 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

(if 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

• Workgroup changes
• OSLC Core v2 retrospecive
  • History of Core spec effort
    • January 2010: First draft written
    • Early issues and decisions
      • The "nothing protocol" just do HTTP, REST and Linked Data the right way
      • Should we base on Atompub protocol? No
      • Should we require RDF/XML? Yes
      • Use approach: define resources and rules for creating representations
    • February 2010: Core workgroup formed, draft spec introduced
    • March 2010: Series of 2 hour meetings to review spec
    • Preconvergence issues and decisions
      • Adopt "value types" of resource and local resource. Also, "representations" of reference and inline
      • Really need resource shapes? Yes
      • Do we need notion of a collection? No
      • Use XHTML for rich text
      • Cannot assume property values are in order
      • Use POST for executing query, with form-encoded parameters
      • Use our own JSON representation
    • April 2010: Core spec v2 converged
    • Convergence issues and decisions
      • Reviewed UI Preview, Link and Partial Update Guidance
      • How to do versioning? Version header, no breaking changes allowed
      • Query Syntax spec is too complex, so we drop oslc.from
      • Worried about Resource Shapes, so we "minimize" them, move them to appendix
      • Added Common Properties appendix
      • Continued work on Link Guidance, which becomes an appendix
      • RDF/XML subset will cause problems later, so we adopt "full" RDF/XML
    • July 2010: Core spec v2 entered finalization
    • May 2011: Core spec v2 final
  • Things that we deferred or tabled
    • Renaming for Response Info and paging properties
    • Formal BNF or ANTLR grammar for Query Syntax
    • Extended Properties
    • Ordered Resources
    • See also OslcCoreV3Plan
  • Round-table: what went well, what could be improved
    • I'll ask each attendee to weigh-in
  • If we need more fodder for discussion we'll touch on key parts of Core spec
    • Glossary
    • OSLC Defined Resources
    • Service Providers
    • Creation Factories
    • Query Capabilties
    • Delegated UI
    • UI Preview
    • Authentication
    • Error Responses
    • Specification Versioning
    • OSLC Defined Resource Representations
    • Appendix A: Common Properties and Resources
    • Appendix B: Representation Guidance
    • Appendix C: Guidance on Links and Relationships

Minutes

Attendees and notes from the meeting

Attendees

Dave Johnson

Steve Speicher

Jim Conallen

Paul MacMahan?

Nick Crossley

Robert Elves

Jim Des Rivieres

Ben Willams

John Arwe

Topics discussed

We changed the agenda for this meeting because Dave Johnson is stepping down from OSLC Core spec lead duties to pursue other opportunities. We decided to use this time to do a retrospective of the Core spec development process. Dave reviewed the history of Core spec development, touching on key dates and issues along the way (see the agenda above). Next, we did a round-table and asked each attendee to comment on what went well and what could be improved.

Steve Speicher: overall good effort and Core spec is good result. One area where we could have done better is conveying the reasoning behind the features in the spec, e.g. explaining why we use RDF/XML, why we need resources shapes, etc.

Jim Conallen: it's very good that there is now a Core spec, defining how things should work, the minutia and protocols so that domains can focus on scenarios and domain specific things. The organization of the Core workgroup and domain workgroups is good. Philosophy of minimalism is good too, don't define specs that do not need to be defined. One comment about workgroups: sometimes domain workgroups have lots of participation up-front, at scenario time, but then participation falls off. One area for improvement is keeping the Core informed about use cases in the domains, because the Core sometimes forgets about domain requirements, e.g. like in AM the number of resource types, transactions, closures, etc. Need clear mandate for workgroup vs. Core spec responsibilities. Core does REST and RDF minutia and workgroups.

Paul MacMahan? : what worked well was the overall approach of Core being basis of domain specs, domain specs are better now, definitely improved inter-operability. Also, Core team's participation in workgroups helped out a lot. Where we can improve: some of the MAY, SHOULD, MUST wording -- Core spec should be more prescriptive, we should be stronger where we can. Also, can improve around Links -- not a lot of guidance around links, how to name a link, how to apply labels, what is security model across links?

Nick Crossley: what worked well was the overall approach of the Core, very good. Also, the workgroup worked well together as a team. One area for improvement is that we focused on making things easy for providers instead of consumers. Too much choice not good for consumers. Need to reduce complexity and flexibility.

Robert Elves: having Core is really great, much better than previous situation. It's good that we went with full RDF/XML instead of trying to abbreviate it. Dave asked about transparency and whether too much work was done "behind the scenes" and Robert responded no, the level of transparency felt right.

Jim Des Rivieres: no comment. I didn't participate that closely and am here mainly to learn from this retrospective.

Ben Williams: mentioned an area for improvement, that being inconsistencies in approaches of different sub-workgroups and the processes followed, e.g. indexing and baselining.

John Arwe: Only joined the effort a couple of months ago. The division of Core and domain workgroups depending on Core makes architectural sense and seems like right division; glad that others agree. What could be improved: better understanding of use cases at Core level. Core should also be scenario and use case driven.

Dave Johnson: I think the overall approach to the Core being "extended" by domains works well. Also, the spec process that Scott and Steve put in place. And, I agree that the workgroup worked well together as a team. What could be improved is more transparency early on. Companies participating should figure out what they want, at a high level and set scope for their employee's efforts as early as possible so community can be involved in new spec work from the start. Another area for improvement is the editing of the specs themselves, including Core. Specs feel a little too informal, unpolished and not as "tight" as other specs. Getting a professional spec author involved would help. Also, our issue tracking is horrible -- we really need a Change Management system.