Hi Mike, Appreciate you raising this discussion on this list. It helps show what implementers are running into and what they need to consider.
To spell out your failing example in detail, it might help the "race" condition that an implementation might get into: 1. Client fetches oslc:Compact resource representations at some URI say http://example.org/thing and gets a 200-OK 2. Someone deletes the corresponding oslc:Compact resource at http://example.org/thing 3. A client gets a 410-Gone if attempted to access the resource at http://example.org/thing 4. A client has already received a valid oslc:Compact representation (step #1) and parses out the URL from the oslc:smallPreview XML element's @rdf:resource as http://example.org/preview?view=small&resource=http://example.org/thing 4a. Client then goes to present the preview by creating an iframe setting the @src to the URL from the previous step Since http://example.org/thing is delete but the implementation GET request asking for HTML using URL http://example.org/preview?view=small&resource=http://example.org/thing It is this implementation's response to return appropriate message, right? A client could be really careful and preform a HEAD on http://example.org/thing to verify the resource is still there This leads me to believe that this is not a spec issue but is an interesting condition that would be good to highlight in some implementers guide. Does this make sense to you? Anyone else have any additional thoughts? Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 > 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 Steve K Speicher/Raleigh/IBM] [attachment "Image2.jpg" deleted by > Steve K Speicher/Raleigh/IBM] _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
