W3C home > Mailing lists > Public > public-ddwg@w3.org > December 2007

RE: [API] Resuming API Work : DDRPropertyValue (including enumerations)

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Tue, 11 Dec 2007 12:39:39 -0000
Message-ID: <D5306DC72D165F488F56A9E43F2045D301677654@FTO.mobileaware.com>
To: <public-ddwg@w3.org>

I'm sure we could pull together a set of units, based on the first draft of the vocabulary that we intend to publish in a few days.

Using URIs to identify units is a nice interoperable and unambiguous way to proceed, though at the back of my mind I have some concerns about implementation efficiency. However, URIs are opaque strings, so all we will be doing is string comparison (for equality testing), which is very efficient if you insist on there only being one instance of each URI string. The equality test is then merely a memory address comparison. Ensuring there are only single instances of the URI strings can be enforced via factory approaches.

As for conversions between units, this is quite a complex issue. As Rhys knows, I've raised this many times in the past in the Device Independence WG. I'll review my notes on the issue and have something more detailed to say on the matter in a day or so.

---Rotan.

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Rhys Lewis
Sent: 11 December 2007 11:55
To: 'Jo Rabin'; public-ddwg@w3.org
Subject: RE: [API] Resuming API Work : DDRPropertyValue (including enumerations)


Hello Jo,

I'm sure that I don't have all the CSS ones in the ontology. However,
adding whatever you'd like to see there is pretty straightforward. Some of
the ones that are there are based on CSS.

To satisfy the good (and I'm hoping less mobility-challenged) Dr.
Hanrahan, it would be nice to get agreement on conversion factors too,
where appropriate. I'll confess to having used the Google calculator up
until now.

Is there a list of units that DD needs anywhere yet?

Best wishes
Rhys

> -----Original Message-----
> From: public-ddwg-request@w3.org
> [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
> Sent: 11 December 2007 11:40
> To: public-ddwg@w3.org
> Subject: RE: [API] Resuming API Work : DDRPropertyValue
> (including enumerations)
>
>
> CSS defines a number of units, are they sufficient for our
> purposes, and are they included in the ontology?
>
> Jo
>
>
> > -----Original Message-----
> > From: public-ddwg-request@w3.org
> [mailto:public-ddwg-request@w3.org]
> > On Behalf Of Rhys Lewis
> > Sent: 11 December 2007 11:36
> > To: 'Rotan Hanrahan'; 'Josť Manuel Cantera Fonseca';
> > public-ddwg@w3.org
> > Subject: RE: [API] Resuming API Work : DDRPropertyValue (including
> > enumerations)
> >
> >
> > Hello Rotan,
> >
> > The ontology currently captures an abbreviation for each
> unit and a name.
> > Both are effectively US English currently.
> >
> > Internationalization of those properties would be
> accomodated in the
> > ontology. I think your suggestion of delegating this kind
> of issue to
> > the ontology is a really good one. It illustrates one of
> the reasons
> > for creating the ontology.
> >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
> > > [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
> > > Sent: 11 December 2007 11:16
> > > To: Josť Manuel Cantera Fonseca; public-ddwg@w3.org
> > > Subject: RE: [API] Resuming API Work : DDRPropertyValue
> (including
> > > enumerations)
> > >
> > >
> > > Regarding [1], I notice the getUnits() method returns a
> String. This
> > > means that all units will have to have a normative textual
> > > identifier. This could be a URI or an agreed short name.
> If we use a
> > > short name, we could run into trouble because some common
> units have
> > > variations in their names. Consider the millimetre, which has an
> > > American spelling of millimeter, and a common abbreviation of mm.
> > > Then there's pixel, which has the same short name in all
> > > English-speaking regions but has a variety of
> abbreviations like p,
> > > px, pix. Even if we choose to use URIs, not all units
> have an agreed
> > > URI. Perhaps these are things that the UWA ontology
> should capture,
> > > and the DD units can simply point to the right place in the
> > > ontology?
> > >
> > > ---Rotan
> > >
> > > -----Original Message-----
> > > From: public-ddwg-request@w3.org
> > > [mailto:public-ddwg-request@w3.org] On Behalf Of Josť
> Manuel Cantera
> > > Fonseca
> > > Sent: 10 December 2007 13:39
> > > To: public-ddwg@w3.org
> > > Subject: [API] Resuming API Work : DDRPropertyValue (including
> > > enumerations)
> > >
> > >
> > > Hi,
> > >
> > > The discussion now need to turn on the DDRPropertyValue
> object and
> > > its methods.
> > >
> > > Please take a look at the current version of this class
> in [1]. The
> > > DDRPropertyValue class is a subclass of DDRValue [2]
> which actually
> > > has all the methods needed to retrieve a property value. It is
> > > important to note that a DDRPropertyValue references the aspect /
> > > component to which the property value applies, which is useful in
> > > those cases where multiple DDRPropertyValues are obtained
> > >
> > > Also it is important to have a look at the way that enumerated
> > > values are treated and how this would be used to query
> about thinks
> > > like image
> > > formats:
> > >
> > > DDRPropertyValue value =
> > > ddr.getPropertyValue("supported_image_formats",key);
> > >
> > > DDREnumeration enumeration = value.getEnumeration();
> > >
> > > if(enumeration.contains("cv:gif")) {
> > >     System.out.println("GIF format is supported for images"); }
> > >
> > >
> > > Please have a look at this proposal and send comments, it is very
> > > important to make progress in the API
> > >
> > > Best Regards
> > >
> > > [1]
> > > http://www.w3.org/2005/MWI/DDWG/drafts/api/java/DDR-API-Minima
> > l/doc/org/w3c/ddr/DDRPropertyValue.html
> > > [2]
> > > http://www.w3.org/2005/MWI/DDWG/drafts/api/java/DDR-API-Minima
> > > l/doc/org/w3c/ddr/DDRValue.html
> > >
> > >
> > >
> >
>
>
>
Received on Tuesday, 11 December 2007 12:40:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:15 UTC