Re: [camp] stupid metadata question #2735

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

Hi Gil,

in-line

On 08/10/2013 18:35, Gilbert Pilz wrote:
> Section 5.24.1 says that the "parameterDefinitionLinks" attribute of the ParameterDefinitions resource is mutable. This seems wrong since TypeDefinitions.typeDefinitionLinks is not mutable nor is Formats.formatLinks nor is Operations.operationLinks yadda, yadda. I'm assuming this is a typo, but I wanted to check to make sure there wasn't some obscure reason for this particular array to be mutable.
seems wrong to me too


On 08/10/2013 19:56, Gilbert Pilz wrote:
> Why is Operations.targetResource (Section 5.26.1) a URI and not a Link? It seems like we need some sort of guiding principle for when to use URIs and when to use Links.
 I thought the guiding principle was:

* URI's for back-links and places where the target is clear

* Links for forward links where user may wish to disambiguate based on 
add'l info (e.g. a targetName)


On 08/10/2013 20:14, Gilbert Pilz wrote:
> Is there any reason that *both* the Operations resource *and* the Operation resource should contain a "targetResource" URI that links back to the target of the operation? Isn't the semantic of Operations.targetResource that all the operations in the sibling operationLinks apply to that resource? Why do the individual Operation resources *also* have to link back to the target resource? Doesn't this, in fact, prevent providers from re-using common operation metadata across different resources - since each Operation can only be linked to one target resource?
It gets confusing if the scope of an operation is not clear.  One simple 
way to make it clear is to scope each operation to a single component.  
This is what we went for.  Back-link at both the Operations resource and 
at each Operation makes it easy to see what the scope is.

If you want to apply an operation to multiple things, one way to handle 
that is with a single component representing the aggregation of those 
things.  This is what I do.

Another way would be an extension which indicates other resources that 
an operation affects.  I think that becomes messier but if people think 
it's a good thing to do I don't mind relaxing the requirement for a 
targetResource.


On 08/10/2013 20:35, Gilbert Pilz wrote:
> Same question as #2736 except for Sensors and Sensor.
And same answer.  ;)


On 08/10/2013 20:43, Gilbert Pilz wrote:
> Section 5.29.4 indicates that the Sensor.value attribute is non-mutable. That seems a little difficult to believe. Typo or dark magic?

Typo from me.  Mea culpa.


--A