Hey Mike, When we think of this from an OSLC point of view (not a product specific implementation view). A request for compact rendering on a resource is done by GETing a resource URL with an Accept header with the compact rendering type. In general when you try to GET a resource that no longer exists a proper response is a 410 Gone.
If we instead respond with a special compact rendering document with a dummy name, links to a valid icon and to at least one HTML resource - we are not exactly (imho) living up to the spirit of linked data. We are essentially manufacturing a resource instead of coming clean and just saying 'it aint there no more'. Additionally if we do it for deleted resources, what about resources that never existed (404), do we also provide a manufactured compact rendering for them? I would hope not. I think the real issue in your comments is the implementation specific UI should handle this better and more consistently. So to directly answer your question, I think this is a defect to be raised on the specific implementation, and not the OSLC specification. Thanks, jim conallen Rational Design Management (DM) Lead Architect, OSLC AM Lead [email protected] Rational Software, IBM Software Group From: Michael A Jaworski/Durham/IBM@IBMUS To: [email protected] Date: 09/23/2011 01:45 PM Subject: [oslc-core] Issue with Compact Rendering of a deleted (410) resource Sent by: [email protected] Hi all, I'm seeing a problem with the widget that controls the compact rendering of a resource (rich hover), specifically after the resource has been deleted. There are two scenarios that I've encountered that exhibit different behavior: 1) Acceptable case: If the resource is deleted before the compact document is fetched, the widget properly recognizes the 410 code returned by the server and disables the rich hover on any following attempts, also displaying a message which says, "More information is not available". (See Image1.jpg attached) (See attached file: Image1.jpg) 2) Failing case: If the resource is deleted after a compact document has been previously fetched, the widget appears to ignore the 410 status returned by the server and attempts to render the compact document again (which instead just displays a nasty 410 exception in plain text). (See Image2.jpg attached) (See attached file: Image2.jpg) >From a server standpoint, our best course of action is to display this nasty exception with as pretty language as possible, but I don't think that's going to be acceptable in the long run. Is this a problem with the current spec? I would appreciate any insight as to why this happens, and whether or not a defect should be filed for this. Thanks, Mike Jaworski Rational Requirements Composer - Server Development[attachment "Image1.jpg" deleted by James Conallen/Philadelphia/IBM] [attachment "Image2.jpg" deleted by James Conallen/Philadelphia/IBM] _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
