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?
- New Query capability example that illustrates how shapes work in relation to query: same question.
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