[Community] OSLC Change Management Working Group Minutes from 4 February 2009
Martin Nally
nally at us.ibm.com
Wed Feb 4 17:39:41 EST 2009
A few questions and comments ....
Is it really useful to have a GET on a "collection of change requests"?
Does anyone ever really want to get back all of them?
What does "except for {property} concensous on query parameters" mean?
Why do we have content-type? Isn't that part of the base HTTP protocol,
not something we need to provide?
"oslc.inline ". Is this necessary? The way you would do this in in SQL
99 is to use "owner->name" as the property in conjunction with
oslc:property
Is there some relationship between a "Collection of Change Request
Definition" and a "Collection of Change Request"?
What is in a "Collection of Change Request Definition "? This is really
2 questions:
what kind of resource is a definition? what does it look like?
which definitions will be in a particular collection?
In the example "GET /changerequest?oslc.state=open&severity=1", what
kind of resource is "/changerequest"? Is it a collection or a request?
"GET /changerequest?oslc.state=open&severity=1". Why is it oslc.state
instead of just state? Where is this dicsussed?
What kind of resource is "/changerequest?oslc.state=open&severity=1"? I
assume the answer is that it's a collection of change requests. If that
is true, that presumably means I can write this:
/changerequest?oslc.state=open&severity=1?oslc.content-type=application/xml.
In general, I assume I can have as many ? as I want, since the url to the
left of each ? identifies a well-defined collection of change requests?
"Formats supported: at least XML, what about JSON". I've written about
this before. GET with multiple content-types is easy, but PUT requires
more thought. If you allow a JSON PUT, it means that the XML is not
being used as an XML document, it's being used as an encoding of a data
structure. This means that if you do a PUT of some XML followed by a
GET, you will not get back the same XML, although you should get back
"equivalent" XML where equivalent means that it encodes the same data
structure. This is ok, but you need to be very clear about it. For
example, you need to specify whether property order will be maintained
or not.
"The request's change request representation can be a subset of the
complete resource". This sounds like you are confusing PUT with PATCH.
With a PUT you are putting the whole resource - the new state of the
resource is entirely derived from the information that is PUT and the
old state is entirely replaced. If you want PATCH semantics, use PATCH:
http://tools.ietf.org/html/draft-dusseault-http-patch-12
"If the element being updated is a collection of items, then the
collection is updated (appended) with the new values. " Same comment.
This is an application of PATCH to collection resources.
Best regards, Martin
Martin Nally, IBM Fellow
CTO, IBM Rational
tel: (949)544-4691
Steve K
Speicher/Raleigh/
IBM at IBMUS To
Sent by: Steve K Andre Weinand/Zurich/IBM at IBMCH,
Speicher Carolyn
Pampino/Lexington/IBM at IBMUS, Dirk
Baeumer/Zurich/IBM at IBMCH,
02/04/2009 02:29 gary.dang at accenture.com,
PM mik at tasktop.com, Rajesh P
Thakkar/India/IBM at IBMIN,
randy.e.vogel at accenture.com, Sam
Lee/Irvine/IBM at IBMUS, Samit
Mehta/San Francisco/IBM at IBMUS,
Scott Bosworth/Raleigh/IBM at IBMUS,
Steve Abrams/Watson/IBM at IBMUS, Tack
Tong/Toronto/IBM at IBMCA
cc
community at open-services.net
Subject
[Community] OSLC Change Management
Working Group Minutes from 4
February 2009(Document link: Martin
Nally)
http://open-services.net/bin/view/Main/CmMeetings02042009
( Let me know of any corrections or directly modify )
Attendees: Steve Speicher, Steve Abrams, Andre Weinand, Scott Bosworth,
Randy Vogel, Sam Lee, Carolyn Pampino, Mik Kersten, Samit Mehta
Minutes:
Introduction of new member: Mik Kersten
Review of ScenariosMylyn with feedback:
Cross-task references cardinality is 0-1, need to be 0-n and
stored in both task repos
Separate out scenarios where schema (shape definition of tasks)
is needed
Organize scenarios as 3 different priority levels to help drive
the spec development
Add scenarios for:
off-line support
details on query for modified by date range
fuzzy search of fine possible duplicates
Review of spec CmRestApi:
Mik acknowledged ATOM as a workable collection
response format
except for {property} concensous on query
parameters
Actions for next meeting:
All review/contribute to specs and supporting
scenarios
Approve specific specification approaches and
supported scenarios for first round of spec
Next meeting: Feb 18, 12-1 Eastern
_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090204/f902f8fe/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090204/f902f8fe/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090204/f902f8fe/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doclink.gif
Type: image/gif
Size: 149 bytes
Desc: not available
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090204/f902f8fe/attachment-0002.gif>
More information about the Community
mailing list