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 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html
