Frank, Some servers have a fixed db schema and are unable to store arbitrary unrecognized content. Therefore, they discard it.
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: Frank Budinsky/Toronto/IBM To: James Conallen <[email protected]> Cc: Adam Neal/Ottawa/IBM@IBMCA, Arthur Ryman/Toronto/IBM@IBMCA, [email protected], [email protected] Date: 09/07/2012 12:07 PM Subject: Re: [oslc-core] Unrecognized content This seems like an odd description anyway. If the server MAY discard property values, shouldn't the spec say that the client MUST assume that the service will discard ... (as opposed to SHOULD)? There doesn't seem to be a choice for the client unless it knows the server implementation (which is bad design practice and would also require no assuming). I also wonder why this design was chosen over the more flexible approach of requiring servers to round-trip properties that they don't recognize? They can ignore them (i.e., treat them like open content) but they can't silently throw them away. Frank. From: James Conallen <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA, Cc: [email protected], Adam Neal/Ottawa/IBM@IBMCA, [email protected] Date: 09/07/2012 11:19 AM Subject: Re: [oslc-core] Unrecognized content Sent by: [email protected] 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 [email protected] Rational Software, IBM Software Group Arthur Ryman ---09/07/2012 10:15:00 AM----1 for the 400 response code Jim, I don't understand what you are asking for. The spec already makes From: Arthur Ryman <[email protected]> To: James Conallen/Philadelphia/IBM@IBMUS, Cc: Adam Neal <[email protected]>, [email protected], [email protected] 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 <[email protected]> To: [email protected] Cc: Adam Neal/Ottawa/IBM@IBMCA Date: 09/07/2012 09:03 AM Subject: [oslc-core] Unrecognized content Sent by: [email protected] 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 [email protected] Rational Software, IBM Software Group _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
