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
