Samit, This is something that we should have clarity on. Though the domain specifications are the ones who define whether certain capabilities are MUST/SHOULD/MAY. The Core specification provides some overall guidance but don't be too restrictive. In the case you site, the CM spec does make them a MUST requirement. In cases like this, I'm not sure there is always a simple answer that covers all cases. We should look at specific cases, much like you pointed out.
Perhaps something that would be great for contributors like yourself to do is to create and keep current a "best practices" page for implementers (both client and server). This doesn't solve your exact issue but helps others in the community learn from what you have learned. Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 > From: Samit Mehta/San Francisco/IBM@IBMUS > To: oslc-core <[email protected]> > Cc: Pat McCarthy/Raleigh/IBM@IBMUS, Scott Fairbrother/Raleigh/IBM@IBMUS > Date: 04/13/2011 05:04 PM > Subject: [oslc-core] Question about how clients should handle server's MAY / > SHOULD requirements > Sent by: [email protected] > > 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:[email protected] > IBM Rational Software - Business Development > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
