Andrew J Berner/Dallas/IBM wrote on 09/28/2010 09:21:19 AM: > From: Andrew J Berner/Dallas/IBM > To: Steve K Speicher/Raleigh/IBM@IBMUS > Cc: Jim des Rivieres <[email protected]>, [email protected], > [email protected], [email protected] > Date: 09/28/2010 09:22 AM > Subject: Re: [oslc-core] Proposed language / modifications to "Range" definition > > So I understand the purpose of not requiring the type. At some point we may > consider whether the type has to support a particular "interface" so that I > can count on it "knowing" relevant information, but let's not go there right now. > > But we don't want to throw out the value of typing while allowing late > binding....If I do know the type (like "often the target resource is another > oslc_cm:ChangeRequest resource) then there is more that I can do with it, > since I have (in my imagination) written my client to use information from > such targets. Can I find out in advance if it is, without having to fetch it? > I may be "out of date"---it the type returned in a header, so I can at worst > have to make a cheap "HEAD" call instead of a GET? Is the type of the target > inlined in the link? Unlike attributes of the target that we should NOT be > denormalizing, that wouldn't change, right?
You can perform a HEAD operation setting an Accept header of what you want, say RDF/XML or JSON or plain XML. You can determine if the service provider supports this. If it does then, take for example, a request for RDF/XML could determine what kind of resource it is based on parsing if you locate the expected rdf:type or locate your properties of interest. Additionally, you could attempt a partial fetch and inspect the result to see if it is something you can work with. The key point is, if we build this tight bindings across systems based on the "type" of resource, we lose some of the flexibility we get from our loose-coupled architecture. So it may be the case that certain use cases may not work if the client can't locate certain properties on that resource but this is not a problem. We just want to be clear in the spec that clients should support this behavior. Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645
