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

[Steve K Speicher]

+1 

When I was looking at RFC2119 before as well, none seemed to be a direct 
hit of the intent of this.
 
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
> To: Ian Green1 <ian.green at uk.ibm.com>
> Cc: oslc-core at open-services.net
> Date: 09/28/2010 12:13 PM
> Subject: Re: [oslc-core] Proposed language / modifications to "Range" 
definition
> Sent by: oslc-core-bounces at open-services.net
> 
> +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 <ian.green at uk.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 09/28/2010 10:58 AM
> Subject:
> Re: [oslc-core] Proposed language / modifications       to      "Range" 
> definition
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net