Meetings/Telecon2018.09.27

Event details

Agenda

  1. Scribe nomination
  2. Roll Call
  3. Approval of Meetings/Telecon2018.09.20 minutes

  4. Next meeting Meetings/Telecon2018.10.04

  5. Actions from the previous meeting
    • Jim to talk with IBM offering management for statements of use
  6. Topics
    • Query spec
  7. Other business

Voting Rights

Held by:

Minutes

Chair

Scribe

Attendees

Resolutions

Actions

Chat transcript from room: oslc

[14:06] Martin Sarabura: Martin to scribe
[14:06] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.09.20
[14:06] Martin Sarabura: Minutes accepted
[14:07] Martin Sarabura: Action: Statement of use for domains spec
[14:08] Martin Sarabura: Need an update of core committee spec, maybe this week
[14:08] Martin Sarabura: Will require another public review
[14:09] Martin Sarabura: There are likely normative changes, should assume we will need another review
[14:10] Martin Sarabura: Action: Martin to line up committee spec review vote for next meeting
[14:12] Martin Sarabura: Martin to fix up Discovery spec
[14:12] Martin Sarabura: Resource shapes will be hardest - conformance clauses all over the place
[14:14] Martin Sarabura: Jim to investigate use of <span> in resource shapes spec
[14:16] Martin Sarabura: David: Better to mark whole cell as conformance clause?
[14:16] Martin Sarabura: Nick: if density of conf clauses is high within table, may be better - make the call on individual basis
[14:19] Martin Sarabura: Purpose of conformance section is to provide one-stop summary of all clauses - OK if it's a little ugly
[14:21] Martin Sarabura: How to deal with mixes of MUST and MAY, and multiple clauses in close proximity to each other, these are problematic and will require judgement call
[14:25] Martin Sarabura: Some discussion of config mgmt
[14:25] Martin Sarabura: Address query feedback next
[14:26] David Honey (Persistent/IBM): Nick's comments by email...
Section 5: I've added a comment to the existing issue 102, to which David has already responded, so I think we have a fix for that. Restate "OSLC properties that have a oslc:queryable "false"xsd:boolean value cannot be specified in oslc.where." to be a conformance clause - perhaps: Servers MUST return an error if a query uses oslc.where terms for properties that have a oslc:queryable "false"xsd:boolean value; see section 10. And then this statement probably belongs in section 6 on using a query capability, or in section 9.2 about oslc.where.
Section 6: The conformance clause QUERY-9 has some missing words: "For a successful operation, the response status code must be 200 OK for a non-paged result, or for an OSLC paged result. [query-9]" should be: "For a successful operation, the response status code must be 200 OK for a non-paged result, or 302 Found or 303 See Other for an OSLC paged result. [query-9]" (and what about 307? Should the above be less prescriptive and just say 'a 2xx or 3xx response'?) In the parameter table, the description of oslc.orderBy has a conformance statement that is not marked as such: If supported, servers should include the oslc:order pseudo-property, and for a paged response, order the pages so that the first page contains the lowest ordered members, and the last page contains the highest ordered members.
Section 7: A question on this requirement: The container must be a Linked Data Platform Container (LDPC) referencing each member resource found by the query. The response should include a Link header that describes the type of LDPC returned. This provides compatibility with OSLC Core 3.0 and its wider use of LDPCs. [LDP] [query-14] The MUST here will make all OSLC 2 servers non-compliant, since they do not currently follow all the rules of LDPCs, such as the mandatory link headers required by the LDP spec itself (despite the SHOULD in the second sentence above). Given that SHOULD in the second sentence, should the MUST in the first sentence be a SHOULD?
Section 8: See Core Issue 102. Query should not require use of oslc:postBody if LDP paging is used. [14:27] Martin Sarabura: Issue 102 - Nick OK with David's comments
[14:27] Martin Sarabura: section 5 - what to do if oslc.where specifies property that doesn't exist
[14:28] Martin Sarabura: Open type system where there isn't a finite enumeration of properties, query should return empty set
[14:28] Martin Sarabura: Except that current systems don't do this
[14:28] Martin Sarabura: All respond with an error
[14:30] Martin Sarabura: If there is a property and defined to be queryable=false, we can't ignore if user tries to query on it
[14:33] Martin Sarabura: Section 5: Will put in the MUST and David will decide where it goes
[14:33] Martin Sarabura: Section 6 = section 9.6...
[14:34] Martin Sarabura: Spec talks about OSLC 2 paging
[14:36] David Honey (Persistent/IBM): http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Paging
[14:37] Martin Sarabura: Does not talk abouut POST, focusing on GET
[14:37] Martin Sarabura: Most browsers will follow a 302 with a GET, so specs often use 303 or 307
[14:38] Martin Sarabura: Rather than referencing 2.0 spec, should we create a new section in the 3.0 spec?
[14:40] Martin Sarabura: May need to clarify in query spec: For paging, will only work for GET and not POST? LDP paging already in the spec...
[14:42] Martin Sarabura: Paging belongs in core spec, not in query
[14:42] Martin Sarabura: Just refer to core
[14:43] Martin Sarabura: Core says use LDP paging or 2.0 core paging - probably not adequate
[14:43] Martin Sarabura: We should copy 2.0 core paging verbiage into core so we can improve the section overall
[14:44] Martin Sarabura: LDP doesn't reinforce possibility of using POST because it doesn't mention it
[14:44] Jim Amsden: Should http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Paging be copied into Core 3.0 overview?
[14:45] Martin Sarabura: Jim to work on this when he works on spec for conformance
[14:48] David Honey (Persistent/IBM): https://issues.oasis-open.org/browse/OSLCCORE-184<<BR>> [14:49] Martin Sarabura: Bookmarking runs risk of server timing out
[14:51] Martin Sarabura: Not ready for a core proposal yet
[14:51] Martin Sarabura: Jim will copy 2.0 stuff into core and we will discuss next week
[14:53] Martin Sarabura: Section 7 discussion
[14:53] Martin Sarabura: Did we already have a vote, specifying MUST?
[14:54] Martin Sarabura: Section 8 - wrong issue #, should be 184
[14:54] Martin Sarabura: Main issue is the paging question
[14:56] Martin Sarabura: Martin to bring the list of meeting links up to date
[14:57] Martin Sarabura: Other items? 183... table for next week?
[14:57] Martin Sarabura: Validating accepts an daccepted-by
[14:57] Martin Sarabura: Nick: Should state that servers should treat properties as readonly and no requirement that they be revalidated
[14:59] Martin Sarabura: meeting adjourned

Meetings/Telecon2018.09.27 (last edited 2018-10-04 12:46:25 by sarabura)