[oslc-core] Question about how clients should handle server's MAY / SHOULD requirements

[James Conallen]

This is an interesting question, and one that I had before. I the answer I
got at the time was that individual service providers would publish
'somehow' exactly what capabilities it supported.

Of course what would help out a lot would be a MUST requirement that
service providers include in the dcterms:publisher value in the
catalog/service provider resource.  That way a client could know which
specific implementation of the server it was talking to, and adjust its
expectations accordingly.

I think the safest option for a client is to assume only the MUST features,
and then only attempt the SHOULDs/MAYs when it can verify a particular
known instance with the provided dcterms:publisher identifier.


<jim/>

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





From:	Samit Mehta/San Francisco/IBM at IBMUS
To:	oslc-core <oslc-core at open-services.net>
Cc:	Pat McCarthy/Raleigh/IBM at IBMUS, Scott
            Fairbrother/Raleigh/IBM at IBMUS
Date:	04/13/2011 05:04 PM
Subject:	[oslc-core] Question about how clients should handle server's
            MAY /	SHOULD requirements
Sent by:	oslc-core-bounces at open-services.net



We have come across at least one requirement (marked as MAY), where it is
unclear how an OSLC service consumer client can determine whether an OSLC
service provider server supports the requirement or not.  Also, it wasn't
clear what the service response would be if a server did not support the
requirement.

Here's the one we ran into:
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Selective_Property_Values

.  There may be others.  The section starts of by saying:
        OSLC Services MAY support a technique called Selective Properties
to enable clients to retrieve only selected property values.

It is unclear how a client may determine that a an OSLC service provider
supports the oslc.properties and oslc.prefix parameters are supported.
Also, is there a specific response that the clients should expect from the
server when they are not supported... is there any way to differentiate
that response from responses returned in other error scenarios?

Regards,
____________________________________________
Samit Mehta
mailto:samit.mehta at us.ibm.com
IBM Rational Software - Business Development




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110414/705799b3/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110414/705799b3/attachment.gif>