OSLC Core Meeting May 19, 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
Probably a short meeting today
Quick review of status
- About 10 open issues on the issues page, about 5 need discussion
- Partial Update proposal under review
- Link Guidance coming this week
How you can help
- Specification is ready for some real proof-reading, please pitch in
- Review the RESOLVED issues on the issues page, did we resolve your issues to your satisfaction?
- Review the Partial Update proposal and give feedback on the mailing list
Current open issues
- OSLC Defined resources
- 21. OPEN No need for NLS string, any string should able to be an NLS string
- 22. OPEN Jim Conallen questions Core's stance on "discard unknown property values" saying that we cannot expect a domain to "define all possible types of file resources it is allowed to version?"
- Response: No change, opaque resources should be created via special creation factory
- Service Provider
- 25. OPEN Use dc:publisher in stead of dc:contributor here
- Query
- 22. OPEN Proposal to defier oslc.from, oslc.offset, etc.
- Response: pending Steve's use cases
- Resource Shapes
- 19. OPEN Resource Shape value-types wrong, don't match those in defined resources section
- 20. OPEN Default property value should be same type as property value itself
- 21. OPEN allowedValues needs work, should be resource or inline
- Response: fix problems but don't add min/max
- JSON
- 4. OPEN Can we remove namespace definitions since we have them in service provider?
- Turtle
- 1. OPEN Need Turtle representation rules, probably just a paragraph
Meeting Minutes
Possible Attendees
We discussed the open issues above. Here are some highlights of the discussion:
On NLS strings, we have consensus that the NLS String value type should be dropped
On the issue of query resource paging parameters, we had an inconclusive discussion, but Arthur made the point that these parameters are optional and therefore do not place a burden on implementations. Issue: what page info should be in responseInfo: Arthur says put them all in the Response Info because, and they're all optional.
We also talked about the need for a separate Common Properties document that is separate from the Core and can grow over time, but did not come out with a definitive proposal for how things should be structured.
We talked about the need for caution when domains start to define properties outside of their own namespace, in place where there could be conflict with other domains.
Topic revision: r2 - 21 May 2010 - 17:39:15 -
DaveJohnson