Re: [API] State of things and plan for the Editor's F2F

Hi,

I think that some of the issues such as the absence of catalogue methods 
were covered in the big initial DDR-API and were temporally dropped to 
get something minimal. I will update the "minimal" with these functions 
so we will be able to discuss this and the other issues in Dublin.

I have no objection about you to be the chair, so if the rest of editors 
agree feel free to draft an agenda which indeed will be very useful to 
prioritize and to keep to time

Thanks ! and Best Regards

Jo Rabin escribió:
> Thanks Jose this is really useful (as is your work on the Java Prototype).
>
> I have some additional issues, some of which overlap with Jose's, that I think need discussion.
>
> Question: I know I am the host, I am wondering who is the chair? If me then I will put an agenda together to try to make sure we keep to time and do what we set out to.
>
> Additional issues:
>
> 1. The current prototype does not include any cataloguing aspects such as "List all known aspects, list all known properties ..."
>
> 2. We don't seem to have a getAllProperties for a particular component to return all the values that are known.
>
> 3. We don't seem to have the ability to get a set of properties all in one go.
>
> 4. That said, the interface seems huge, do we really need something this overwhelmingly big?
>
> 5. We seem to have a package called DDR and an interface called DDR that are not related which, forgive me being simple minded :-), I find confusing. In fact we could probably usefully spend some time working through naming and naming conventions.
>
> 6. Instantiation. I think we should revisit this. I am a little concerned that one could instantiate am Identification and a Service (those names should change) that are not compatible with each other. I'm also pondering whether as well as being able to instantiate different code, one should be able to instantiate different versions of datasets. 
>
> Like I say, all at the same time as working to make the interface smaller and simpler.
>
>
> 7. By symmetry the Identification interface should offer version getting capabilities and some other stuff on the service interface.
>
> 8. Don't understand what "setProperty" is on Service.
>
> 9. We need to define a minimal conformance subset for all this.
>
> 10. Can't we just specify "iterable" instead of having separate classes? (Also we specify contextKeyList - should it be a set and shouldn't it be iterable?)
>
> Regards
> Jo
>
>
>
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
> Sent: 21 January 2008 11:59
> To: public-ddwg@w3.org
> Subject: [API] State of things and plan for the Editor's F2F
>
> Hi, 
>
> As per the action I took on last telco I'm sending out this e-mail to summarize the state of things wrt the Core API [1]:
>
> State of the things
> -------------------
>
> + The DDR interface is nearly finished although there are some decisions I think we need to revisit (see below). The only thing that we need to make a final decision is wrt units. 
>
> Next work
> -----------
>
> + ContextKey interface. During the F2F in Boston We dropped the getHandle interface . We need to revisit the decision as the implementation experience has demonstrated that this is something needed, not only for Java but also for WSDL (Rodrigo can give us more information :) )
> + Exceptions. We need to define all the exceptions that the API will need 
> + DDRIdentification interface. We need to agree on the methods of this interface. Particularlly we need to define how will be the interfaces to be used at design time. 
> + DDRFactory. In the current protoype the DDRFactory is got from the DDRService interface. We need to agree on this
> + Constants Constants are needed to deal with enumerated values. We need to decide whether we are going to define constants in the Jaba binding
> + Aspects We need to think more on this. An initial vocabulary of aspects could be based on UAProf and the DC ontology. With respect to the API, we need to define how are we going to access to aspects, perhaps a combination of a factory plus a set of constants
> + getActiveComponent. I think we need to revisit this methods as its have dynamic connotations and our API is only intended  for static info stored in DDRs
> + units We need to reach to a final agreement regarding units in the API and in general
> + bootstrapping interfaces. We need to treat this
> + DDRMeta interface. We need to treat this
> + FacetedProperties that can take a maximum, minimum, default and actual (see [1]) 
> + IDL-WSDL (Rodrigo has been dealing with this and provided he attends the F2F he can enlight us with his conclusions. There is an initial version of the WSDL commited in [2] 
>
> Best Regards
>
> [1] http://www.w3.org/2005/MWI/DDWG/drafts/api/java/DDR-API-Minimal/doc/
> [2] http://www.w3.org/TR/2007/WD-dcontology-20071221/#PixelCount
> [3] https://forge.morfeo-project.org/plugins/scmsvn/viewcvs.php/trunk/?root=ddr-ri
>
>
>

Received on Wednesday, 23 January 2008 18:08:48 UTC