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.

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:

Meeting Minutes

Attendees

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
Topic revision: r3 - 05 May 2010 - 15:50:47 - DaveJohnson
 
This site is powered by the TWiki collaboration platform 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