[oslc-core] Guidelines for specifying future-proof resources/capabilities

[Steve K Speicher]

Dave <snoopdave at gmail.com> wrote on 05/06/2010 08:04:23 AM:

> From: Dave <snoopdave at gmail.com>
> To: oslc-core <oslc-core at open-services.net>
> Date: 05/06/2010 08:04 AM
> Subject: [oslc-core] Guidelines for specifying future-proof 
> resources/capabilities
> Sent by: oslc-core-bounces at open-services.net
> 
> re: Specification versioning
> 
> I'm still working representations today, but I've been thinking more
> about the guidance that we should provide in Core spec to help
> workgroups specify "future proof" resources.
> 
> The rule
> 
>    * A new version of an OSLC specification is not allowed to
> introduce changes that will break old clients.
> 
> The guidelines
> 
> For OSLC workgroups, these are some guidelines to help you live with
> the above rule and specify OSLC resources that are as future-proof as
> possible.
> 
>    1) Think you need a property but cannot agree on the value-type?
> This is a strong indication that you should not attempt to standardize
> on the property. Once decide on a value-type you are stuck with it
> forever. Wait until you have the scenarios or implementation
> experience needed to agree upon a value-type.

I would argue that there is value in a domain spec defining the meaning of 
a property, without agreeing on its type.  Dublin Core does this, it 
doesn't define any value-types for its properties.
Though, walking through an example: if a provider defines priority 
property to be the value-type to be a String and in later OSLC-CM spec we 
define it to be a resource say PropertyChoices, the client would have to 
be smart enough to adopt to the new shape definition.  It could know this 
as the associated oslc:instanceShape would have changed, as well as the 
resource's etag/dc:modified.

Perhaps if the resource shape, or domain definition of the resource, could 
clearly define these type of properties as having an *open* definition for 
value-type then a client could predictably handle such cases.

[SNIP]

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100512/16662003/attachment-0003.html>