+1 I think this gets the right amount of clarity and nuance: Description: The target resource is a related change request. It is likely that the target resource will be a ChangeRequest, but that is not necessarily the case.
From: Ian Green1 <[email protected]> To: [email protected] Date: 09/28/2010 10:58 AM Subject: Re: [oslc-core] Proposed language / modifications to "Range" definition Sent by: [email protected] RFC2119 MAY is being used here as a hint - setting an expectation. My suggestion is to put some non-normative text along the lines of "it is likely that the target resource will be a ChangeRequest, but that is not necessarily the case". Description: The target resource is a related change request. The target resource MAY be another oslc_cm:ChangeRequest resource. best wishes, -ian [email protected] (Ian Green1/UK/IBM@IBMGB) Chief Software Architect, Requirements Definition and Management IBM Rational [email protected] wrote on 28/09/2010 14:47:12: > [image removed] > > Re: [oslc-core] Proposed language / modifications to "Range" definition > > Steve K Speicher > > to: > > Andrew J Berner > > 28/09/2010 14:47 > > Sent by: > > [email protected] > > Cc: > > oslc-core, oslc-cm > > 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 > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
