Re: [API] Code snippet I .- fast property retrieval (not unit aware)

Hi all,

my understanding of our discussion at the F2F is, I think, the same as
Jo's one: the logic to get the property value in different units will be
inside the PropertyValue object. So the PropertyValue should have
methods (like propertyValue.GetValueInUnit("mm")) for different units
where appropriate.

What I understand from Jose is that this snippet will be appropriate for
a property with no units (or where the units are implicit) like, maybe,
"color depth" (probably better than "resolution_width"). In this case
there is no need for additional methods in order to get the property in
different units.

To me, to have a toString() method at the class level will mean to
return the value, that has no units as a String. For a property with
different possible units, this method could return the value expressed
in "default units".

Again, for a property with different possible units, the PropertyValue
class can have methods like

propertyValue.getDefaultUnits()
propertyValue.getUnitsList()

and

propertyValue.getValueInUnit("some")


That was my idea from the F2F... what do you think about?


Rafa

-------- Mensaje Original --------
>> My understanding is that you and others wanted the API to be capable of
>> returning values in a choice of units.
>>     
>
> Correct.
>
>   
>> My understanding of our discussion at the F2F was that specifying the
>> units was to be something that PropertyValue would cater for, which
>> implies something like:
>>     
>
>   
>> propertyValue.GetValueInUnit("mm").toString();
>>     
>
> Ah. I see where there is confusion. This was not what I took from what José said:
>
>   
>> Also from my example it seems to be good (at least in Java) to have an 
>> implemented toString() method at the level of DDRPropertyValue that will
>> return the property value as an String, simplifying even more the task for
>> the developer, that will print the value with System.out.println(value)
>> where value is a DDRPropertyValue object.
>>     
>
> To me, this is saying that the PropertyValue class itself would have a toString(). If you are providing the class with a GetValueInUnit(u) method, then what is the return class of that method? Boolean? Integer? Float? In any case, the return class is not another instance of the PropertyValue class, or we would be going around in circles.
>
> I can see the utility of having a GetValueInUnit(u) method. If this returns an appropriate boxed type (as I previously suggested) then for most languages, and certainly Java, there is an automatic toString() method, and it doesn't include units, because the boxed type is neutral.
>
> What I was thinking of was more like this:
>
> propertyValue.toString("mm"); // for cases where you want to override the default units
>
> and
>
> propertyValue.toString(); // which uses the default units as per the vocabulary
>
> and
>
> propertyValue.getValueInUnits(u); // which returns a boxed type (e.g. Integer) that itself has no units, but which is implied in the parameter you passed in
>
>
> How does this sound?
>
> ---Rotan
>
>
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
> Sent: 20 November 2007 11:39
> To: public-ddwg@w3.org
> Subject: RE: [API] Code snippet I .- fast property retrieval (not unit aware)
>
>
>
>
>
>   
>> -----Original Message-----
>> From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com]
>> Sent: 20 November 2007 11:19
>> To: Jo Rabin; public-ddwg@w3.org
>> Subject: RE: [API] Code snippet I .- fast property retrieval (not unit
>> aware)
>>
>> I was observing that toString() doesn't include a parameter to
>>     
> indicate
>   
>> what units (if any) should apply when interpreting the returned
>>     
> string.
>   
>> So I conclude that to interpret the string we should already know
>> something such as the default units, or know that no units apply.
>>
>> So it boils down to how you know the units in advance. If you know
>>     

> (from
>   
>> the vocabulary perhaps) that the physical width will be represented in
>> millimeters/millimeters, then that's good, because now the string
>> doesn't have to contain the units. If that is what you are suggesting,
>> then I'm happy with that. It means, of course, that we need to decide
>> where this a priori knowledge about the units will be represented. I
>> think perhaps the vocabulary might be a viable place. I'm hesitant to
>> suggest putting this in the ontology because the ontology his wider
>> applicability and we could not be certain that the default units we
>> choose would be the same as those chosen in other use cases.
>>     
>
> My understanding is that you and others wanted the API to be capable of
> returning values in a choice of units.
>
> My understanding of our discussion at the F2F was that specifying the
> units was to be something that PropertyValue would cater for, which
> implies something like:
>
> propertyValue.GetValueInUnit("mm").toString();
>
> Yes, there is the need for some properties to have known units. 
>   
>> This feels like an argument about angels on the head of a pin. I think
>> we're actually in agreement. The answer is 42, right?
>>     
>
> I expect so.
> Jo
>
>   
>> ---Rotan.
>>
>>
>> === original dialogue ===
>>
>> [snip]
>>
>>     
>>> What is the justification for not including units in the string
>>> representation? Perhaps it would be the temptation to parse the
>>>       
> string
>   
>>> (which is definitely not something I would want to see). However, if
>>>       
>> an
>>     
>>> application intends to display the strings to a human then there
>>>       
>> should be
>>     
>>> some way to know a) if the human should be interpreting the string
>>>       
> in
>   
>> some
>>     
>>> units, and b) what those units are. So either we introduce the idea
>>>       
> of
>   
>>> default units for the toString() of any value to which units can
>>>       
>> apply, or
>>     
>>> we include the units in the string. If I were to merely present
>>> "0.000000000001" as an output with no indication of what it means,
>>>       
>> then
>>     
>>> what's the point? It's meaningless garble.
>>>       
>> If I ask for the value in parsecs, then I expect the returned value in
>> parsecs. I know what the unit is before I get it back. If I am
>>     
> careless
>   
>> enough not to represent that in user output, well, then I'm an idiot.
>> That's not the DDR's problem. If I am less careless, I may choose to
>> represent the unit in any way I like, especially for example, spelling
>> "millimetre" or "millimeter".
>>
>> Jo
>>
>> [snip]
>>     
>
>
>