Thiago, Your Change request is independent from this patch which means your -1 should be set into new Jira ticket.
Anyway, I agree that common attribute such as if, rt, href attribute key should be prohibited from IoTivity attribute setting API. I expect someone make the patch for this logic. However, resource spec based filtering looks strange because IoTivity cannot follows the whole spec context and update. BR, Uze Choi -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Thursday, March 03, 2016 2:23 PM To: jihun.ha at samsung.com Cc: ???; Habib Virji; iotivity-dev at lists.iotivity.org; 'Jon A. Cruz' Subject: Re: [dev] Review to a patchset for collection payload On quinta-feira, 3 de mar?o de 2016 02:47:19 PST ??? wrote: > Hi. Thiago, > > What you've pointed as a problem sounds less persuasive to me. > > If one wants to define a vendor-specific attribute, OIC specification > already gives a certain rule for naming: > Resource Attribute : x_[vender]_[attributekey] > e.g. x_samsung-com_speed Hello Jihun Is it written in the spec that all properties, even for vendor-specific resource types, need to start with "x_" ? I'm not talking about vendor-specific properties in standard resource types, but of entire resource types. > And if vendors or developers implement a OIC-compliant resource > server/client application, they already know OIC specification and > that it defines only 4 resource properties: if(interface), rt(resource > type), p(policy), and n(name) (Note that the spec calls them to > "common properties"). They don't know the spec that hasn't been written yet. That is, they can't predict which common properties we may want to add later, say in 2018. > And it mentions "its non-common properties(i.e. resource > attributes) shall not use the name of existing common properties". Good. > My point is that IoTivity developers will rationally avoid to use a > same attribute with one of the resource properties. IoTivity developers don't come into this equation. We don't decide what the property names are. > Additionally, OIC specification thinks that resource attribute and > property are same categorized information. That is why the spec calls > the resource attribute and property to "property" and "common > property", respectively. I see. It seems that the OIC spec is trying to be future-safe. We just need to ensure two things: 1) someone keeps a list of all property names used, in each and every official/ standard resource type (maybe parsing the RAML files is enough) 2) NO ONE is allowed to add new property names, even in vendor-specific resource types, except OIC/OCF itself. For example, resource type "com.samsung.freezer" can't have a property of "defrost" (it has to be "x_samsung_defrost"), but it may have a property "temp" because "oic.sensor.temperature" has that. I want to see a volunteer for the Change Request before I change my -1. Note: the maintainer does not have to wait for me. He can approve despite my -1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
