search

jamsden / oslc-core-test

0 stars 0 forks source link

Clarify the meaning of multi-part OSLC Core 3.0 specification re: conformance #4

Open jamsden opened 5 years ago

jamsden commented 5 years ago

It was not clear exactly what OSLC Core is. Is it:
1. All of the specifications - any compliant server would be expected to implement all of the capabilities (including those referenced from LDP).
2. Any of the specifications - a compliant server could advertise only one of the core capabilities, e.g., Resource Preview.

The OSLC Core Overview specification should clarify that compliance to OSLC core means with respect to the component specifications.

jamsden commented 5 years ago

From: ndjc - I think this part is too weak: "OSLC Core Discovery may allow clients to determine what capabilities are provided." I think we need to design Core Discovery so that it does allow such determination, to at least the SHOULD level if not MUST.

jamsden commented 5 years ago

I updated the content above, and provided some motivation for even treating OSLC Discovery as optional. Since this section is non-normative, it needed specify MUST or SHOULD on discovery.

It doesn‘t seem that OSLC Core Discovery should be required. Rather a server could specify what it supports through some other means (documentation), and clients could be developed to use those capabilities (e.g., preview dialogs) without having to dynamically discover their existence.

jamsden commented 5 years ago

From: martinpain - Sounds right to me - that everything discoverable is optional (unless required by the server‘s chosen domain specification(s)), and that technically discovery itself is optional.

Re: Nick‘s comment, "The OSLC Core Discovery capability may allow clients to determine what capabilities are provided by a server." might be better as "The purpose of OSLC Core Discovery capability is to allow clients to determine what capabilities are provided by a server."

jamsden commented 5 years ago

From: ndjc - I did not intend to imply that discovery should be mandatory. However, the original wording implied that even when discovery was present, it might not allow the client to discover what capabilities are provided. Martin‘s suggested wording change fixes this.