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

Reply via email to