OSLC Core Meeting May 5, 2010

Meeting logistics

See the OslcCoreMeetings for more information, more dial-in numbers and on-line meeting information.

• Conference Access
  • Toll free: 1-866-423-8350
  • Toll: 1-719-387-8273
• Participant passcode: 558663

Agenda

Today I would like to discuss the last two open issues: specification versioning and query representation.

The issues are:

• New versioning proposal resulting from special WG meeting last week: any questions or concerns?
  • http://open-services.net/bin/view/Main/OslcCoreMeetings04302010
• New Query capability example that illustrates how shapes work in relation to query: same question.
  • http://open-services.net/bin/view/Main/OslcCoreQueryDiscussion

Meeting Minutes

Attendees

• DaveJohnson
• JimConallen
• ArthurRyman
• ScottBosworth
• NickCrossley

On the topic of specification versioning

• ScottB? : make it clear that we are introducing a version number header is to differentiate Core with pre-Core, and to allow pre-Core clients to continue to work. Once specs conform to the Core, they can evolve without changing a version number string.
• NickC? : The no-header-v1-implied rule does not apply to domains that never had a v1 pre-Core version

On the topic of specification versioning & Guidance for Designing resources

• ScottB? : guidance on properties applies to all, not just those that are required
• ScottB? : Good guideline is - if you think you need a property but cannot agree on type, then don't standardize it yet
• DaveJ? : Also - think you need a property then consider whether you want to support it forever
• ScottB? : need guidance for when you need to add a new capability; define a new service provider entry
  • e.g. new type of query, then define a new capability, oslc_cm:SpecialChangeRequestQueryCapability

DaveJ? : having to send an OSLC-Version header in a GET is obnoxious, can we add a oslc-version URL parameter

On the topic of Query Capability discussion & need for shape

• DaveJ? : do you really have to list every type of resource as a member property, can we be generic
• ArthurR? : yes, you could have one member property that uses a "abstract base class" type of shape
• NickC? : we don't need to build any type hierarchy into the Core spec, we have what we need now to do generics like this
• ScottB? : do we really need to have a shape for a query capability, seems burdensome
• ArthurR? : its not unreasonably burdensome

On the topic of Query Capability discussion

• NickC? : how much of the simple query syntax is really required by the Core?
• ArthurR? : different parts are specified MAY, SHOULD and MUST
• DaveJ? : we already do this, see how the Reporting spec defines which parts of Query it needs
• ArthurR? : add the "queryable" property back into oslc:Property.

On the topic of Query Capability & Atom

• DaveJ? : does Atom feed representation look reasonable?
• ArthurR? : yes
• ArthurR? : Add a dc:description to oslc:ResponseInfo, it will be useful in some cases