[oslc-cm] [oslc-core] Proposed language / modifications to "Range" definition
Andrew J Berner
ajberner at us.ibm.com
Tue Sep 28 09:21:19 EDT 2010
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?
Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com
Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Steve K Speicher/Raleigh/IBM at IBMUS |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-cm at open-services.net, oslc-core at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|09/28/2010 07:59 AM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [oslc-core] Proposed language / modifications to "Range" definition |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-core-bounces at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Hi Jim,
You have good points, I may write it slightly different. By indicating it
as "MAY" it implies that clients should be prepared to handle any kind of
resource.
Description: The target resource is a related change request. The
target resource MAY be another oslc_cm:ChangeRequest resource.
Is this better?
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> wrote on 09/24/2010
02:36:22 PM:
> From: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
> To: Steve K Speicher/Raleigh/IBM at IBMUS
> Cc: oslc-cm at open-services.net, oslc-core at open-services.net
> Date: 09/24/2010 02:36 PM
> Subject: Re: [oslc-core] Proposed language / modifications to "Range"
definition
>
> > "Description: This relationship is loosely coupled and has no
> > specific meaning. The value of this property MAY refer to another
> > oslc_cm:ChangeRequest resource."
>
> This wording is ambiguous. It can be read as denying that the
relationship
> itself has any meaning, instead of the target resource being
unconstrained
> to any particular type.
>
> Also, the name of the property strongly suggests that there is some
> expectation of the type of the target resource. To capture this
> expectation while making it clear to consumers that they cannot count on
> it, you could say something like:
>
> Description: The target resource is a related change request. While the
> target resource SHOULD be another
> oslc_cm:ChangeRequest resource, the target resource MAY be any kind of
> resource.
>
> Regards,
> Jim des Rivieres | IBM Rational Software | (613) 356-5015
>
>
>
> From:
> Steve K Speicher <sspeiche at us.ibm.com>
> To:
> oslc-core at open-services.net
> Cc:
> oslc-cm at open-services.net
> Date:
> 09/24/2010 01:59 PM
> Subject:
> [oslc-core] Proposed language / modifications to "Range" definition
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
> Last core meeting I took an action to propose some changes to domain
> specifications on how "Range" should be used for relationship properties
> that were not "closed". Where not "closed" implies that other kinds of
> resources could potentially live at the other end of the URI reference.
> The need was to make sure that consumers knew that the intent of the
> relationship was to loosely coupled and open, therefore encouraging
> clients to be flexible in handling the de-refencing of these
relationship
> URIs.
>
> Here is a sample of the change for the CM spec [1] and the
> relatedChangeRequest relationship property:
>
> New proposed changes::
> Range: any
> Description: This relationship is loosely coupled and has no
> specific meaning. The value of this property MAY refer to another
> oslc_cm:ChangeRequest resource.
>
> Original:
> Range: oslc_cm:ChangeRequest
> Description: This relationship is loosely coupled and has no
> specific meaning.
>
> Note: I made the change in the spec [1] for only the one property
>
> Looking for feedback on this proposed change.
>
> [1] http://open-services.net/bin/view/Main/CmSpecificationV2
>
> 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
>
>
>
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Cm
mailing list