Will the notion of "null" help with an issue that was discussed in the Architecture Management workgroup--the sematics of leaving out a property on a "PUT": does it mean "delete the property from the resource" or does it mean "I don't even know that property exists"...perhaps a client setting it to "NULL" can mean delete, reserving leaving it out for "not part of the interface I know how to consume."
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 |------------> | From: | |------------> >-----------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >-----------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >-----------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >-----------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >-----------------------------------------------------------------------------------------------------------------------------------------| |11/14/2009 11:00 AM | >-----------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >-----------------------------------------------------------------------------------------------------------------------------------------| |Community Digest, Vol 11, Issue 6 | >-----------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> >-----------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >-----------------------------------------------------------------------------------------------------------------------------------------| Send Community mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://open-services.net/mailman/listinfo/community_open-services.net or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Community digest..." Today's Topics: 1. Re: Request for Comment on Common Query Syntax V1 (Steve K Speicher) 2. Re: Request for Comment on Common Query Syntax V1 (Arthur Ryman) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 Nov 2009 13:27:50 -0500 From: Steve K Speicher <[email protected]> Subject: Re: [OSLC] Request for Comment on Common Query Syntax V1 To: [email protected] Message-ID: <ofe6f748dd.c30ece73-on8525766d.0064c8a5-8525766d.00656...@us.ibm.com> Content-Type: text/plain; charset="us-ascii" Arthur Ryman <[email protected]> wrote on 11/06/2009 10:20:19 AM: > 2. Nested properties. The CM version allowed nested properties via > {}. This is very useful, both for query and inlining of results. I > suggest we add this to the spec. +1 > 3. The query parameter names. The CM spec used oslc_cm:query and > oslc_cm:properties for what are essentially the WHERE and SELECT > clauses of a query, i.e. oslc_cm:query is like the WHERE clause and > oslc_cm:properties is like the SELECT clause. Since query is an > overloaded term, I suggest we use oslc:select and oslc:where for > these parameters, or oslc_select and oslc_where if you don't like colons. I like the naming oslc:filter and oslc:properties. That way a consistent convention can be used to request the amount of properties whether it is either a single resource request or when requesting a collection of resources will inlined properties. So for a single resource: GET /bug/1?oslc:properties=dc:title,dc:description or collection/filter result: GET /bugs?oslc:filter=state="new"&oslc:properties=dc:title,dc:description Additionally, I've received some requests to add the concept of "null" as a value. Something such as oslc:NULL. Then you can do statements such as owner=oslc:NULL Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://open-services.net/pipermail/community_open-services.net/attachments/20091113/b71aab81/attachment-0001.html > ------------------------------ Message: 2 Date: Sat, 14 Nov 2009 18:51:18 +0530 From: Arthur Ryman <[email protected]> Subject: Re: [OSLC] Request for Comment on Common Query Syntax V1 To: Steve K Speicher <[email protected]> Cc: [email protected], [email protected] Message-ID: <of4c8a56fd.4713d55c-on6525766e.0048bc0d-6525766e.00495...@ca.ibm.com> Content-Type: text/plain; charset="us-ascii" Steve, Thx for the feedback. For NULL, we need to define the semantics since we are thinking in terms of RDF. Does NULL mean the property doesn't exist? (in the case of optional properties). Arthur Ryman, IBM DE Chief Architect, Rational Project and Portfolio Management Office: 905-413-3077, Cell: 416-939-5063 Assistant: Nancy Barnes, 905-413-4182 Steve K Speicher <[email protected]> Sent by: [email protected] 11/13/2009 11:57 PM To [email protected] cc Subject Re: [OSLC] Request for Comment on Common Query Syntax V1 Arthur Ryman <[email protected]> wrote on 11/06/2009 10:20:19 AM: > 2. Nested properties. The CM version allowed nested properties via > {}. This is very useful, both for query and inlining of results. I > suggest we add this to the spec. +1 > 3. The query parameter names. The CM spec used oslc_cm:query and > oslc_cm:properties for what are essentially the WHERE and SELECT > clauses of a query, i.e. oslc_cm:query is like the WHERE clause and > oslc_cm:properties is like the SELECT clause. Since query is an > overloaded term, I suggest we use oslc:select and oslc:where for > these parameters, or oslc_select and oslc_where if you don't like colons. I like the naming oslc:filter and oslc:properties. That way a consistent convention can be used to request the amount of properties whether it is either a single resource request or when requesting a collection of resources will inlined properties. So for a single resource: GET /bug/1?oslc:properties=dc:title,dc:description or collection/filter result: GET /bugs?oslc:filter=state="new"&oslc:properties=dc:title,dc:description Additionally, I've received some requests to add the concept of "null" as a value. Something such as oslc:NULL. Then you can do statements such as owner=oslc:NULL Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://open-services.net/pipermail/community_open-services.net/attachments/20091114/26e52ebc/attachment-0001.html > ------------------------------ _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net End of Community Digest, Vol 11, Issue 6 ****************************************
