Date:
4 Feburary 2010 Time:
7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa Call In Number: (emailed)
Participation request: contact
JimConallen
Agenda
- Quickly summarize points from last meeting.
- Review the detailed scenarios. We will make sure that all the essential scenarios are covered.
Minutes
Atendees: Brenda Ellis, Jim Amsden, Thomas Piccoli, Jim Conallen
The team continued reviewing the detailed scenarios, beginning with the Create an AM resource. Jim A. asked who defines the content types? Jim C. responded that each service provider must declare what it accepts, and clients should only submit resource that the service can understand, otherwise the service will reject.
Jim C. asked if the response type (oslc am resource format) was appropriate, and there was general agreement that it was.
Jim A. asked if it was possible to submit a resource in the OSLC AM format. Jim C. said that the spec certainly allows it, assuming the service provider is willing to accept it. Jim A. also suggested that we update the examples to show this specific example. Jim C. suggested we inlude an opaque example like submitting Power Point decks.
Tom asked how clients would know the difference between a rejection based on unsupported content type versus, insufficient privledges. Jim C. said that in both cases a 403 response is returned, but the message would indicate the reason.
Jim A. raised some concerns regarding the use of ETags to manage concurrent modification. Unless the resources are very granular, there will be some difficulties in an environment with lots of modifications. Jim A. described how
WebDAV? addresses this, and warned of the reliance on just ETags.
Jim C. mentioned that we need a page that details exactly what elements should be expected in ATOM collections.
Jim C. asked if we should allow wildcards in queries in the place of link types, when looking for resources with relationships to external resources. The team agreed that this would be a good thing to allow.
Jim A. suggested that for the link types collection we use RDFS instead of inventing a new content type (and in general for all meta data). Jim and Jim agreed to take that conversation off line and report back to the team.