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

[Andrew J Berner]

Steve wrote:

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.

I understand why that helps the people defining the spec...the flexibility
allows the spec to apply in many situations that may be incompatible
otherwise.  So we can get more providers.

But help me understand how a consumer would then write code portable among
those providers (test every property to see what type it is and have case
statements to do conversion???), and how, if it changes from version to
version, a client would continue to work when the version is updated (or do
providers then have to provide multiple versions).   Common model across
providers and backwards compatibility are two key requirements for a usable
interface.

I certainly may be misunderstanding and may not be familiar with the
techniques to handle these issues, but then I suspect that will be true of
many potential users.


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