[occi-wg] Incorporating units into OCCI

[Gary Mazz]

Andre,

Maybe I've misinterpreted what was proposed? I though if a particular 
industry infrastructure, like broadcast and telecom, natively uses a 
terminology like bits, the spec won't support their native terminology.  
For example cable channels, satellites and  mpeg is commonly referred to 
bits.

By not supporting the native units of an industry, you infer that is not 
an industry your specification recognizes. I'm sure that's not the 
intent, but that is how it may be interpreted.

-gary


Andre Merzky wrote:
> Quoting [Gary Mazz] (May 26 2009):
>   
>> I think units are a very important issue. More significant than 
>> atom/json/xlm discussions. I think someone pushed a satellite  into 
>> mars  over a foot/meter  discrepancy.
>>
>> What  if its an e911 or other emergency application running on a cloud. 
>> It really helps to reduce operational risk with a page of text in a spec.
>>     
>
> I am not saying they are not important - but it does not
> matter on *which* one you agree, as long as we agree on
> something, and the spec is clear about that...
>
> Andre.
>
>
>   
>> -gary
>>
>> Andre Merzky wrote:
>>     
>>> Oh well...  - you can't make everybody happy.  At the end
>>> one needs to decide on one of the options, and either way,
>>> just getting rid of units (by defining them as fixed) seems
>>> like a good solution.  As others stated: a UI can always
>>> represent a more suitable version...
>>>
>>> A
>>>
>>> Quoting [Gary Mazz] (May 26 2009):
>>>  
>>>       
>>>> Just as an fyi, media folks work in "bits"
>>>>
>>>> -gary
>>>>
>>>>
>>>> Andre Merzky wrote:
>>>>    
>>>>         
>>>>> Quoting [Sam Johnston] (May 26 2009):
>>>>>
>>>>>      
>>>>>           
>>>>>>> a 4th option, which i rather prefer since the units stuff tends to be
>>>>>>> relevant to and consumed by humans via UI rather than machines via 
>>>>>>> API,
>>>>>>> is not to use units at all.
>>>>>>> <memory>2147483648</memory>
>>>>>>> either of the above is far easier to transform to and from non-XML
>>>>>>> representations, in my experience, with the latter being zero effort.
>>>>>>> a couple extra bytes won't harm us and we adhere to my first
>>>>>>> engineering rule: the best solution to a problem is not to have it in
>>>>>>> the first place.
>>>>>>>     
>>>>>>>          
>>>>>>>               
>>>>>>  Andy and I spent a few hours on the phone tonight getting ourselves
>>>>>>  aligned and this was basically the conclusion we came to as well
>>>>>>  (though we were talking about choosing e.g. megabytes for memory,
>>>>>>  gigabytes for disk and gigahertz for processors). 
>>>>>>   
>>>>>>        
>>>>>>             
>>>>> I think that is a great compromise: simple format, + human
>>>>> readable.
>>>>>
>>>>> Andre.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      
>>>>>           
>>>
>>>  
>>>       
>
>
>
>