[oslc-core] Unrecognized content

[Arthur Ryman]

Jim,

I disagree. The server ignored the content it didn't understand and did 
the update, but the before and after state was the same. According to your 
proposal, if I did a GET and then immediately PUT the resource, that 
should also result in an error because nothing changed. That would not be 
reasonable.

Consider the following Java program:

int x = 42;
x = 42;

That shouldn't result in a compiler error. 

In fact, the behavior of the server is somewhat undefined if a PUT would 
result in no change to the resource. The server could try to be clever and 
only update the resource if some property changed. Or it could take the 
request literally and replace the resource with an identical copy, but as 
a side affect, the modification date of the resource might change. 


Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational 

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
James Conallen/Philadelphia/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
09/07/2012 11:16 AM
Subject:
Re: [oslc-core] Unrecognized content


Hey Arthur,

The spec for the PUT method says:

If an existing resource is modified, either the 200 (OK) or 204 (No 
Content) response codes SHOULD be sent to indicate successful completion 
of the request. If the resource could not be created or modified with the 
Request-URI, an appropriate error response SHOULD be given that reflects 
the nature of the problem.  

In this scenario the server did not modify the resource, because it didn't 
recognize the content.  So according to RFC 2616 we should be returning an 
error response.


Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group






From:   Arthur Ryman <ryman at ca.ibm.com>
To:     James Conallen/Philadelphia/IBM at IBMUS, 
Cc:     Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net, 
oslc-core-bounces at open-services.net
Date:   09/07/2012 10:15 AM
Subject:        Re: [oslc-core] Unrecognized content



-1 for the 400 response code

Jim, I don't understand what you are asking for. The spec already makes it 

clear that the server will discard unrecognized content. The client should 

expect that. What aspect of behavior is unclear?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational 

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
James Conallen <jconallen at us.ibm.com>
To:
Oslc-Core at open-services.net
Cc:
Adam Neal/Ottawa/IBM at IBMCA
Date:
09/07/2012 09:03 AM
Subject:
[oslc-core] Unrecognized content
Sent by:
oslc-core-bounces at open-services.net



In the current specification we have the statement:
For OSLC Defined Resources, clients SHOULD assume that an OSLC Service 
will discard unknown property values. An OSLC Service MAY discard property 

values that are not part of the resource definition or Resource Shape 
known by the server.

We are running into a problem. When a client (in this case another 
application server) PUTs an update to a resource that includes a 'link' to 

another OSLC resource, and the server, at the time does not recognize the 
link type, the link is not accepted, but a 200 OK is returned.  The server 

returns a 200 OK, because it feels like it can ignore the unrecognized 
link.  The client gets that 200 OK, and thinks that the link was 
successfully added.

This doesn't feel right.  The only way a client can be sure that the PUT 
worked as expected is to re-GET the resource and compare it to what it 
expected to see (with the new link included), and maybe do a little 
looking at ETags to make sure things haven't changed in between.

I guess the server could instead return a 400 Bad Request, and include in 
the response the reason for not accepting the PUT.  But if the content 
that was submitted really should just be ignored (i.e. is part of a future 

version of the resource), then we don't want to abort the update.

The OSLC verbage does not provide any guidance as to what to do.  It would 

be helpful if we had more detailed explanation of this statement in the 
spec.


Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net