Minutes from OSLC Core TC meeting June 11

["Sarabura, Martin" <msarabura@ptc.com>]

Below are the minutes for the meeting on Thursday - slightly delayed as I was on vacation. Please respond regarding your intention to attend the meetings especially during the summer months where we may have trouble achieving quorum due to vacation. The next meeting is scheduled for June 25. The calendar entry https://www.oasis-open.org/apps/org/workgroup/oslc-core/event.php?event_id=39864 has a hyperlink for "planning to attend".

Note also we may have an email vote to accept the full compatibility statement, subject to review of the OASIS rules by Nick. Also we may continue to schedule ad-hoc meetings to discuss specific issues at any time.

Thanks,

Martin Sarabura

R&D Fellow, PTC

 

 

 

Chair

Martin Sarabura

Scribe

Nick Crossley

Attendees

• Harish (SoftwareAG)
• Jim Amsden (IBM)
• Martin Sarabura (PTC)
• Nick Crossley (IBM)

Regrets

Resolutions

Actions

• Nick to look up info on email voting

Chat transcript from room: oslc

[07:07] List of attendees: Harish (SoftwareAG), Jim Amsden (IBM), Martin Sarabura (PTC), Nick Crossley (IBM)

[07:08] Nick Crossley (IBM): Martin: asked for review and approval of the minutes of the previous meeting

[07:09] Nick Crossley (IBM): Martin: minutes were approved

[07:11] Nick Crossley (IBM): Martin: action item from last meeting: Martin was asked to see if he could find more info on how OSLC standards are being used in the field. Advice from Chet was to canvas other TCs in OASIS.

[07:11] Nick Crossley (IBM): Martin: should we consider some form of registration of users for OSLC 3.0, and if so, how?

[07:12] Nick Crossley (IBM): Martin and Jim are less concerned now that our approach is one of more compatibility

[07:14] Nick Crossley (IBM): Martin: Users do not have to disclose why they object to removing some feature (to address a concern of proprietary information)

[07:15] Nick Crossley (IBM): Jim: If we address compatibility, and allow normative references to OSLC v2, I think there is no longer a significant issue

[07:17] Nick Crossley (IBM): Topic - v2 compatibility

[07:17] Jim Amsden (IBM): https://wiki.oasis-open.org/oslc-core/V2Compatibility

[07:18] Nick Crossley (IBM): Jim: moved discussion from issue list to the above wiki page to allow more formatting, editing, capabilities

[07:18] Nick Crossley (IBM): Jim: also tried to capture motivation for compatibility, and also start a clear list of areas of compatibility

[07:20] Nick Crossley (IBM): Jim: for paging - if LDP paging is standardized, clients/servers will need to decide whether to use OSLC 2 paging or LDP paging

[07:21] Nick Crossley (IBM): Jim: primary directive copied right out of OSLC Core 2.0 spec

[07:22] Nick Crossley (IBM): Jim: features categorized as compatible, obsolescent, incompatible - and the last is the areas we need to work on

[07:25] Nick Crossley (IBM): Jim: are there any of the items on the 'potentially incompatible' list that we should discuss? Do members agree that we need to work on making these compatible to conform to the directive for client compatibility?

[07:26] Nick Crossley (IBM): Nick: I edited the vocabulary section to clarify the proposal for shapes

[07:26] Nick Crossley (IBM): Jim: Let's go through each item.

[07:29] Nick Crossley (IBM): Jim: Authentication - not much there except possibly the version of OAuth, and some URIs in 2 not currently in 3. If we resolve the discovery issues, we can continue to use the OAuth URIs from 2.0

[07:29] Nick Crossley (IBM): Jim & Nick: OAuth was difficult to understand, difficult to get right, difficult to diagnose when things did not work

[07:33] Nick Crossley (IBM): Jim: discovery is probably the biggest issue. One approach is to say there are two forms of discovery - an up-front semi-static form of discovery using OSLC 2.0 specs, and a more dynamic form of OSLC 3 discovery using LDPCs

[07:33] Nick Crossley (IBM): Jim: What do we feel about normative references to sections of the Core 2.0 spec?

[07:33] Nick Crossley (IBM): Nick & Martin: some concerns that the result would not be well-defined.

[07:35] Nick Crossley (IBM): Agreement that we probably need to extract those parts of the 2.0 spec into a new page for the 3.0 spec - keeping some separation of areas that we might want to deprecate in the future

[07:36] Nick Crossley (IBM): Jim/Martin: How do we proceed? May not have enough attendance today to make a final vote. What about an email vote?

[07:36] Nick Crossley (IBM): Action item: Nick to look up info on email voting.

[07:37] Nick Crossley (IBM): Martin: Should we add a section on specification versioning to OSLC 3.0, carrying forward the intent from OSLC 2.0?

[07:37] Nick Crossley (IBM): Nick: +1 from me on that

[07:39] Nick Crossley (IBM): Nick: the compatibility constraint was also there to instruct domain specifications on how they evolve

[07:40] Nick Crossley (IBM): We agreed to include an equivalent compatibility section - public review gives people a chance to object if they want

[07:43] Nick Crossley (IBM): Jim: Some changes to dialog properties needed for compatibility

[07:45] Nick Crossley (IBM): Nick: On optional properties, while it may be technically permissible to drop such properties from the 3.0 specs, we should exercise caution before doing so - it might introduce gratuitous incompatibility between servers if they reinvent the dropped property in different ways

[07:46] Nick Crossley (IBM): Jim: we should address the asymmetry between height & width in the dialog & resize specs.

[07:47] Nick Crossley (IBM): Jim: dropping support for older browser techniques should be acceptable

[07:47] Nick Crossley (IBM): Martin: the compatibility concerns should be more nuanced - if there is a problem in the older spec, we should be allowed to fix it

[07:49] Nick Crossley (IBM): Jim: query support is an interesting topic. It seems as if a fundamental query service is a general requirement. We should refer from 3.0 to the OSLC 2.0 spec - but as a last resort. Servers should probably be recommended to use other query standards such as SPARQL

[07:52] Nick Crossley (IBM): Nick: I have lowered the Config Mgmt requirement for OSLC Query support from MUST to MAY

[07:54] Nick Crossley (IBM): Martin: did OSLC consider supporting named queries, where a query is a resource with a shape, clients create an instance of that resource and GET it to run the query

[07:55] Nick Crossley (IBM): Jim: this is more or less what an LDPC can do (and hence the direction for OSLC 3.0 at the moment), but does this achieve interoperability? Not really, because there is no common agreement on the nature of such named query LDPCs and their shapes

[07:57] Nick Crossley (IBM): Martin: lack of info on idiosyncratic capabilities is also a barrier to interoperability

[08:00] Nick Crossley (IBM): Nick: OSLC 2 didn't define the number and nature of query capabilities well, so interoperability is tricky anyway

[08:05] Nick Crossley (IBM): Nick: What about selective property retrieval? OSLC 2 allowed that on any GET?

[08:05] Nick Crossley (IBM): Jim: Missed that - need to add it to the compatibility list

[08:08] Nick Crossley (IBM): Jim: Paging. OSLC 2.0 has a paging section (not a separate spec page), and LDP has a paging proposal. OSLC 3.0 currently silent. We probably have to copy out the 2.0 section and add it to 3.0

[08:09] Nick Crossley (IBM): Martin: unstable paging is an important thing to mention, otherwise stable paging introduces a significant constraint and cost for servers

[08:12] Nick Crossley (IBM): Jim: propose that OSLC 3 suggest a resource has either oslc:instanceShape pointing to an OSLC 2 resource shape OR ldp:constrainedBy pointing to something not yet defined that might become a W3C shape

[08:12] Nick Crossley (IBM): Nick: +1

[08:18] Nick Crossley (IBM): Jim: OSLC Core 3.0 should reference TRS 2.0. TRS specs (and Linked Data Provider Guidance) should remain at open-services.net - and normative references can be made to them - until/unless a new version of those specs/documents is required. At that time, interested parties could form a TC to establish an OASIS version of TRS.

[08:25] Nick Crossley (IBM): No further comments on attachments, actions, automation, error responses

[08:27] Nick Crossley (IBM): Jim: On vs:term_status - how valuable is this? Is anyone or any software actually going to take note of a deprecation warning? And would we deprecate anything anyway? Our compatibility requirements contra-indicate any such action.

[08:27] Nick Crossley (IBM): Martin: Warning of deprecation is a useful way of prompting feedback from potential users.

[08:28] Nick Crossley (IBM): Jim: You can get the same feedback using 'SHOULD NOT', 'MAY' or 'MAY NOT' and similar wording in the specs.

[08:28] Nick Crossley (IBM): Jim: SHOULD NOT is not machine discoverable, but not sure of the value of run-time discovery of such statements

[08:31] Nick Crossley (IBM): Discussion on vs:term_status = experimental - agreement that there's really no place in a standard for use of experimental terms.

[08:33] Nick Crossley (IBM): Jim: suggest putting up an email vote for completion by 15 days from now - one day after the next meeting

[08:33] Nick Crossley (IBM): Martin: any other business? No, so meeting adjourned