OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Query 3.0 specification updates

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]