[oslc-core] Issue with Compact Rendering of a deleted (410) resource

[James Conallen]

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
jconallen at us.ibm.com
Rational Software, IBM Software Group





From:	Michael A Jaworski/Durham/IBM at IBMUS
To:	oslc-core at open-services.net
Date:	09/23/2011 01:45 PM
Subject:	[oslc-core] Issue with Compact Rendering of a deleted (410)
            resource
Sent by:	oslc-core-bounces at open-services.net



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
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net