Yes, the tool based language binding generators that I am aware of "hard wire" in the current semantics in the way that Martin describes, which is a primary reason why I don't consider the current tool-based language binding generators a good approach. But a group of humans that understand both the extensibility capabilities of the language, and the extensibility mechanisms of the REST services, can define a language binding that cleanly provides both generic extensible methods (to handle future extensions), and type-checkable methods for the current semantics. But it isn't easy, even for a smart group of humans (:-).
Cheers, Geoff From: Martin Nally/Raleigh/IBM@IBMUS To: Paul McMahan/Raleigh/IBM@IBMUS Cc: [email protected], [email protected] Date: 02/03/2010 02:19 PM Subject: Re: [OSLC] Generating language bindings for the OSLC interfaces Sent by: [email protected] I'm not a fan of approaches like JAXB. The basic assumption of JAXB and a whole raft of similar technologies is that the set of properties of an "entity" is fixed and so can be compiled into a Javabean/POJO with getter and setter methods. This is a very seductive approach for Java programmers (or users of other programming languages of that style), but it introduces major problems. What happens if next week that entity has more properties? It might even have fewer properties in the future - if the properties that disappeared are ones that the logic of the application didn't happen to use it shouldn't affect the application. Why might an entity have more or fewer properties in the future? One scenario is version evolution - the entity got richer over time. Another scenario is the dynamic addition of properties that are specific to a usage. For example, for defects, the most prominent use-case/application is change management, so the natural starting point is to define a set of properties for that purpose. Later, someone might come along with a planning application that needs to add some more properties. An estimation application might need another set of properties. An archival application might add an expiry date. The point is that the set of properties of a defect might evolve not only through increasing richness of a defect schema over time, but through the dynamic addition of new applications without central schema control. So how should a client be programmed to deal with this? If I were coding it, I would explicitly avoid technologies like JAXB (and EMF and other equivalents) which are unlikely to have the flexibility to deal with this kind of dynamism. What would I do instead? I would probably use simple Java Maps (or the equivalent in your chosen language). Out of curiosity, I might look at some of the RDF libraries out there, but I'd tread very cautiously. Maps are just name, value pairs, grouped into sets and RDF is basically the same idea with a little bit more formal specification and a large dose of pretentiousness. I would avoid XML Schema like the plague - it's much too static. Bottom line - I personally think JAXB, EMF and other such POJO-generators are a poor technology choice for OSLC client and server implementations - they are too static - and so I would not be in favor of promoting their use. I understand not everyone is going to agree with my position on JAXB, EMF etc. I would also avoid XML Schema. This also is unlikely to attract consensus. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: (949)544-4691 Paul McMahan---02/03/2010 01:11:22 PM---I've had some success using JAXB to generate a java binding from an XML schema which describes vario From: Paul McMahan/Raleigh/IBM@IBMUS To: [email protected] Date: 02/03/2010 01:11 PM Subject: Re: [OSLC] Generating language bindings for the OSLC interfaces Sent by: [email protected] I've had some success using JAXB to generate a java binding from an XML schema which describes various OSLC resources and service description documents. The binding basically maps XML to/from POJO. From what I understand there are similar tools for other languages. So I'm interested in the idea of using tools to generate bindings for the resources and service documents that flow across the standard GET/PUT/POST/DELETE calls. I'm curious how this approach might work in terms of RDF schema since it has advantages over XML schema, and whether its applicable for representations other than XML. Best wishes, Paul McMahan Rational Quality Management [email protected] Martin Nally/Raleigh/IBM @IBMUS To Sent by: Steve K Speicher/Raleigh/IBM@IBMUS community-bounces cc @open-services.ne [email protected], t [email protected] Subject Re: [OSLC] Generating language 02/03/2010 12:17 bindings for the OSLC interfaces PM Has anyone outlined what those bindings would look like? Don't all the languages already have API for GET/PUT/POST/DELETE? The goal of a REST-based design would be that there is nothing beyond this except the ability to understand the domain-specific resource formats. An RDF library might be useful for this. What else would be useful? Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: (949)544-4691 (Embedded image moved to file: pic10293.gif)Inactive hide details for Steve K Speicher---02/03/2010 08:29:16 AM---Andy, For CM domain I see it playing out as #1 as most ofSteve K Speicher---02/03/2010 08:29:16 AM---Andy, For CM domain I see it playing out as #1 as most of the interfaces define (Embedded (Embedded image moved to file: pic30196.gif) image moved to Steve K Speicher/Raleigh/IBM@IBMUS file: pic28856.gif) From: (Embedded (Embedded image moved to file: pic10400.gif) image moved to [email protected] file: pic20291.gif) To: (Embedded (Embedded image moved to file: pic28662.gif) image moved to 02/03/2010 08:29 AM file: pic19343.gif) Date: (Embedded (Embedded image moved to file: pic04625.gif) image moved to Re: [OSLC] Generating language bindings for the OSLC file: interfaces pic14108.gif) Subject: (Embedded (Embedded image moved to file: pic25262.gif) image moved to [email protected] file: pic00816.gif) Sent by: Andy, For CM domain I see it playing out as #1 as most of the interfaces define deeper semantics on REST style hat can't be exposed easily in most commonly available tools that I'm aware of. We see this now with Eclipse Mylyn and their exposure of a consumer Java API. I see JavaScript bindings to be of interest as well. I have not heard of any C#/C++ requests as of yet, though PHP (as a service provider) I have. Now speaking for Rational products that use the CM interfaces, we utilize common code (both Java and JS) which has been manually developed. Regards, Steve Speicher | IBM Rational Software | (919) 254-0645 [email protected] wrote on 02/03/2010 05:14:14 AM: > To use the OSLC interfaces effectively, client programmers need an easy way > to get 3GL language bindings to program against the interface. In > practice, most ALM tools, which are the prime candidates to use the > interfaces, would benefit from either a Java or C# binding. I can imagine > two ways of getting these bindings: > > a) For each interface, someone in the community, or a group of members, > produce the binding by hand and maintain it as the interface evolves > > b) Clients use a set of commonly available tools to generate bindings > > Can someone from each workgroup comment, please, on how this can be > addressed for the interface under development? Which language bindings are > of interest (testing my hypothesis that Java and C# will suffice for most > of the community)? > > Andy Berner > Lead Architect, ISV Technical Enablement and Strategy > IBM Rational Business Development > 972 561-6599 > [email protected] > > Ready for IBM Rational software partner program - > http://www.ibm.com/isv/rational/readyfor.html > > > _______________________________________________ > Community mailing list > [email protected] > http://open-services.net/mailman/listinfo/community_open-services.net _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net [attachment "pic10293.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic28856.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic30196.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic20291.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic10400.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic19343.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic28662.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic14108.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic04625.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic00816.gif" deleted by Martin Nally/Raleigh/IBM] [attachment "pic25262.gif" deleted by Martin Nally/Raleigh/IBM] _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
