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

I also have no objection to Jo chairing this meeting. I chaired the last meeting where we spent hours going through the early API design and it was exhausting! So thanks Jo :)
 
I believe that the participants in this meeting will have sufficient experience and expertise to do a good job in advancing the API. However, I would like to state now (taking off my Group Chair hat) that I would like us to avoid going down purist rat-holes and just focus on creating an API that is "reasonable" and "developer-friendly", without having to worry about it being perfect. If the meeting chair can not only keep us on time but also keep us practical/pragmatic, then I will be happy.
 
Looking forward to seeing you all next Monday.
 
---Rotan.
 
 

________________________________

From: public-ddwg-request@w3.org on behalf of José Manuel Cantera Fonseca
Sent: Wed 23/01/2008 18:11
To: Jo Rabin
Cc: public-ddwg@w3.org
Subject: 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 22:10:59 UTC