Query 3.0 specification updates

["Jim Amsden" <jamsden@us.ibm.com>]

Here's the updates I did to the query specification.

* Fixed this, previous and latest version
links so ReSpec generates the proper published URIs

* changed short name to oslc-query since
this is a different specification than oslc-core, this is also reflected
in the version URIs.

* Reorganized the document to conform
to the latest OASIS guidelines: Introduction: IPR Policy, Terminology,
References, Namespaces, Typographical conventions.

* Moved Version Compliance to just before
Conformance

* Moved and renamed Compatibility with
OSLC Query 2.0 to Appendix A (so that Acknowledgements and Change History
are at the end).


ISSUE: "For a successful operation,
the response status code must be 200 OK for a non-paged result, or for
an OSLC paged result" - OSLC Core paging indicates the server can
send a 302 if it thinks the resource is too large and wants to page the
result even though the client didn't request paging. Is this missing something?

ISSUE: end of section 4. Using a Query
Capability: do oslc.paging and oslc.pageSize need to be included here since
they are defined in Core and apply to any resource?

ISSUE: "If a GET or POST on a query
base URI neither specifies oslc.where nor oslc.searchTerms, the server
must return a query response describing all the resources that have one
or more of the RDF types specified by the oslc:resourceType of the oslc:QueryCapability
that defines the oslc:queryBase. [query-12]", What if the query capability
service doesn't specify any resourceType? Does that mean any resource type
might be returned?

ISSUE: "An OSLC domain specification
MAY use some or all of these query parameters, and should use these rather
than defining new query parameters that have the same or very similar meanings.
Each of these query parameters SHOULD appear at most once in a query. The
behavior is undefined when a query parameter appears more than once. [query-20]"
looks like two separate and very different conformance clauses. I don't
think the former is a conformance clause: this spec says what server implementations
do, not what domain specification developers do.

For future consideration: should all
the examples use curl? This would 1) show the exact GET with the query
parameters, and would avoid having to deal with ugly encoded string. 

ISSUE: the RTC examples have ugly GUIDs
in the URLs. Should we rename these to something more readable? They just
make the spec look ugly.

ISSUE: where semantics - do we need
to say that % and _ need to be escaped to match them as literals?

Example 8 (searchTerms) and 9 (orderBy)
show the GET, but don't show the result.

* Removed Client SHOULD or Client SHOULD
NOT from conformance clauses. OSLC doesn't make constraints on clients,
only server implementations. 

Re: orderBy and OSLC 2.0 compatibility,
should we indicate that servers SHOULD order the triples in the RDF serialization
format, perhaps at least for RDF/XML, if we assume a lot of existing clients
are using XML DOM/XPath to "parse" the query results, and not
RDF parsers?




Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575