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

> 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]

Received on Tuesday, 20 November 2007 11:49:38 UTC