RE: RE: [API] First draft of the Java API bindings

> > Thus we may need to have some inspection mechanism explicit in the API. 
>
> Actually there is one. There is a DDRPropertyRetrievalState (which is
> based on the values proposed by Jo in the current Editor's Draft) that
> flags what is the result of retrieving a property, for example if the
> value finally retrieved is Composite, Enumerated, etc. So using this
> mechanism we can solve the problem in those languages that does not
> have 'instanceof' mechanisms.

Excellent. I missed that on my first pass through the source.

---Rotan.

-----Original Message-----
From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es] 
Sent: 11 October 2007 07:07
To: Rotan Hanrahan
Cc: public-ddwg@w3.org
Subject: Re: RE: [API] First draft of the Java API bindings

Hi,

> For example, the DDRPropertyValue may need some mechanism for
determining the data type

Yes, now it has a getProperty method that only returns the property id and namespace. There would be no problem in returning a DDRPropertyMetadata that contains all the meta info about a property, or at least a 'Minimum meta info' that at least contains the property type :) .

>In the example given below, the displayed value is obtained via an  
>implied toString(). We cannot assume that strings will suffice as  
>representations of values in a language binding. Some values will  have 
>structures, such as the value that might represent the set of  
>supported image formats.

That's the reason because there are subclasses of DDRPropertyValue, for example, EnumeratedDDRPropertyValue is the class that allows to retrieve value sets.  

> Thus we may need to have some inspection mechanism explicit in the API. 

Actually there is one. There is a DDRPropertyRetrievalState (which is based on the values proposed by Jo in the current Editor's Draft) that flags what is the result of retrieving a property, for example if the value finally retrieved is Composite, Enumerated, etc. So using this mechanism we can solve the problem in those languages that does not have 'instanceof' mechanisms. 

Best Regards

----
José Manuel Cantera Fonseca
Telefónica I+D

----- Mensaje original -----
De: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Fecha: Miércoles, Octubre 10, 2007 9:25 pm
Asunto: RE: [API] First draft of the Java API bindings
Para: José Manuel Cantera Fonseca <jmcf@tid.es>, public-ddwg@w3.org

> Excellent start to this work. Thanks Jose.
> 
> Obviously we will have plenty to consider as we move this towards an 
> agreed structure for the API. For example, the DDRPropertyValue may 
> need some mechanism for determining the data type, and any data type 
> should be considered with regard to the UWA ontology types.
> 
> In the example given below, the displayed value is obtained via an 
> implied toString(). We cannot assume that strings will suffice as 
> representations of values in a language binding. Some values will have 
> structures, such as the value that might represent the set of 
> supported image formats. Thus we may need to have some inspection 
> mechanism explicit in the API. We cannot rely on an "instanceof"
> mechanism inherent in the target language. (Or can we? Would IDL 
> experts care to comment?)
> 
> At least now we have some source code to focus our thinking. Let's 
> keep the momentum going.
> 
> ---Rotan.
> 
> ________________________________
> 
> From: public-ddwg-request@w3.org on behalf of José Manuel Cantera
> FonsecaSent: Wed 10/10/2007 18:20
> To: public-ddwg@w3.org
> Subject: [API] First draft of the Java API bindings
> 
> 
> 
> 
> Dear All,
> 
> I have created a first draft of the Java API bindings [1], even I'm 
> proud to announce that I have a first version of the implementation of 
> those APIs using WURFL :). I have done it as a proof of concept of the 
> quality of the design.
> 
> I have designed all the functions that are in the current editor's 
> draftand others that might be in subsequent drafts. Also a simple 
> bootstrapping mechanism is provided.
> 
> I think this APIs should provide a good starting point for those who 
> are not comfortable with IDL. Also, I'm gonna send a UML diagram 
> illustrating the design of the API. I will also commit in the group's 
> CVS the Java files.
> 
> The main entry points to the API are the interfaces:
> 
> + DDRAdmin
> + DDR
> + DDRMetadata
> + DDRIdentification
> 
> [1] http://www.w3.org/2005/MWI/DDWG/drafts/api/DDRAPI-JavaBinding/
> 
> Using the APIs the code to call a DDR could as simple as:
> 
>        DDRServiceRegistry registry =  
> DDRServiceRegistryImpl.newInstance();        DDRService service = 
> registry.newDefaultDDRService();        
> service.setProperty("WURFL_FILE", "resource/wurfl.xml");
>        service.initialize();
> 
>        DDRIdentification recognition = 
> service.getDDRIdentification();        Map headers = new 
> java.util.HashMap();        headers.put("User-Agent", "MOT-
> T720/G_05.01.43R");        ContextKey key = 
> recognition.identifyByHttpHeaders(headers);
>        DDRProperty prop = new DDRPropertyHelper("resolution_width");
>        DCComponent device = new DeviceComponentHelper();      
>        DDRPropertyValue value =
> service.getDDR().getPropertyValue(key,prop,
>                device);
>        System.out.println("Retrieved value:" + value.getValue());
>      
>        DDRPropertyValueList list =
> service.getDDR().getAllPropertyValues(key, device);                 
>  
>          
>        for(int j = 0; j < list.getSize(); j++) {
>            System.out.println("Capability: " +
> list.item(j).getProperty().getId() + " values " +
>                    list.item(j).getValue());
>        }
> 
> 
> 
> 
> 
>

Received on Thursday, 11 October 2007 09:00:32 UTC