[Community] OSLC Change Management Working Group Minutes from 4 February 2009

Steve K Speicher sspeiche at us.ibm.com
Fri Feb 6 15:01:37 EST 2009


nally at us.ibm.com wrote on 02/04/2009 05:39:41 PM:

> A few questions and comments ....
> 1. 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? 
A GET on a collection of change requests without query parameters is 
typically not done.  For completeness in this case we were looking at 
leaving it mostly unspecified but giving guidance of returning a page of 
results (limit of 20) or a 405 Forbidden.

> 2. What does "except for {property} concensous on query parameters" 
mean? 
Means we are looking for a more robust GET-based query syntax, to avoid 
namespace and other path math issues

> 3. Why do we have content-type? Isn't that part of the base HTTP 
> protocol, not something we need to provide? 
It is and we are attempting to remove some ambiguity around what clients 
place in the Accept header.  An approach is at 
http://open-services.net/bin/view/Main/CmRestApi#requestedformats

> 4. "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 
We'll log as an issue and follow up with the originators of this.  It 
appears that as you say, inline may not be needed.

> 5. Is there some relationship between a "Collection of Change 
> Request Definition" and a "Collection of Change Request"? 
Not directly.

>From the "Collection of Change Request", one could discover a change 
request resource and it could have a reference to it's shape definition 
(schema).  For example, find Bug123 which has a property of <type>
http://host/types/BugType</type>
>From the "Collection of Change Request Definitions", one could discover a 
collection of resource shape definition (schemas) of which one would be 
the same as the previous example

> 6. What is in a "Collection of Change Request Definition "? This is 
> really 2 questions: 
> 1. what kind of resource is a definition? what does it look like? 
Typically something like XML Schema.  Though we haven't gotten that far

> 2. which definitions will be in a particular collection?
The definitions of all the variants of OSLC CM change request resources, 
ex. Bug, Feature, ...

> 7. In the example "GET /changerequest?oslc.state=open&severity=1", 
> what kind of resource is "/changerequest"? Is it a collection or a 
request? 
It is a collection.

> 8. "GET /changerequest?oslc.state=open&severity=1". Why is it 
> oslc.state instead of just state? Where is this dicsussed? 
It should be just "state", working draft typo.

> 9. 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? 
Yes, that is correct.  The URL query parameters (?) filter the response of 
the resource collection request.

> 10. "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. 
We have this issue identified as we need to elaborate on this more.

> 11. "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 
Marked as something to rework (issue)

> 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.
(same as above)

> 
> Best regards, Martin
> 
> Martin Nally, IBM Fellow
> CTO, IBM Rational
> tel: (949)544-4691
> 

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/community_open-services.net/attachments/20090206/228cb04b/attachment-0003.html>


More information about the Community mailing list