Dave <[email protected]> wrote on 05/06/2010 08:04:23 AM: > From: Dave <[email protected]> > To: oslc-core <[email protected]> > Date: 05/06/2010 08:04 AM > Subject: [oslc-core] Guidelines for specifying future-proof > resources/capabilities > Sent by: [email protected] > > 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
