I like Jim's suggestions and think your edit is a nice incremental improvement - seems to me that the MAY language is more indicative of what clients should expect than the initially suggested SHOULD language....Scott
Scott Bosworth | IBM Rational CTO Team | [email protected] | 919.486.2197 (w) | 919.244.3387(m) | 919.254.5271(f) From: Steve K Speicher/Raleigh/IBM@IBMUS To: Jim des Rivieres <[email protected]> Cc: [email protected], [email protected] Date: 09/28/2010 08:59 AM Subject: Re: [oslc-cm] [oslc-core] Proposed language / modifications to "Range" definition Sent by: [email protected] 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 <[email protected]> wrote on 09/24/2010 02:36:22 PM: > From: Jim des Rivieres <[email protected]> > To: Steve K Speicher/Raleigh/IBM@IBMUS > Cc: [email protected], [email protected] > 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 <[email protected]> > To: > [email protected] > Cc: > [email protected] > Date: > 09/24/2010 01:59 PM > Subject: > [oslc-core] Proposed language / modifications to "Range" definition > Sent by: > [email protected] > > > > 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > _______________________________________________ Oslc-Cm mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
