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:39:22 UTC