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

Apart from the naming of the methods (which we never actually discussed), you are saying much the same as I was saying. The getDefaultUnits and getUnitsList are interesting. They would be useful for interrogation of a property, but in the request-time use case I'd say that a developer would already figure out which units were appropriate and would probably only use the getValueInUnit(u) method, where "u" is a know supported units measurement of the property in question.

 

---Rotan.

 

From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Rafael Casero
Sent: 20 November 2007 14:58
To: public-ddwg@w3.org
Subject: 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]