[oslc-core] Proposed language / modifications to "Range" definition

[Ian Green1]

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

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational

oslc-core-bounces at open-services.net 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:
> 
> oslc-core-bounces at open-services.net
> 
> 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 at IBMUS
> > Cc: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>, 
> oslc-cm at open-services.net,
> > oslc-core at open-services.net, oslc-core-bounces at open-services.net
> > 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
> Oslc-Core at open-services.net
> 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