[oslc-core] Multi-types resources in JSON representation

[Andrew J Berner]

James Conallen said:

> So the general rule for a client is, if a property could be multi-
> valued, then to access it you MUST check to see if it is an array
> first, if not then access it as a single valued object, if it is an
> array then access each value through the array. Is anyone concerned
> that this might be a burdensome pattern for clients?

Why can't the spec be that properties that may be multi-valued are
represented by an array, which could be an array of one element.  For
providers whose data model will always be a single value for some property
that is allowed to be multi-valued, since the provider is specifically
formatting the document according to the spec anyway, this isn't a burden
on the provider and makes it simpler for the client.  This is both a
development issue (having to make the checks), and a run-time issue,
especially with large queries of resources with many attributes.  Good
encapsulation can help with the development issue (which is usually one of
my big concerns and I think needs more attention in general).

Now, I'll give an argument against that...if in an early version of the
spec the property is single valued, but then a later version of the spec
changes it to multivalued, if the spec allows multi-valued attributes that
happen to have only one value in a resource to be a single valued object,
then old resources are still compatible without conversion.  Even if that's
a good goal, the client of the newer version can deal with it by handling
the exception, but this helps the runtime issue--"most" resources over time
at least will have the uniform representation, rather than randomly varying
from provider to provider.

Andy Berner