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: Re: [oslc-core] OSLC Core in whole and in part


My understanding is that all the core specifications are intended to define particular capabilities that servers MAY support if it makes sense for them to do so.

In the Core overview, phrases such as "have layered capabilities" and "OSLC MS-affiliated TC developed specifications may depend on OSLC Core 3.0 specifications as scenarios motivate" hint at this, but you're right that we should say it explicitly.

Perhaps the only one that would be absolutely necessary would be the discovery spec, but as it currently stands that doesn't include any MUST statements anyway.

I think perhaps the point is, that saying that a server is "compliant with OSLC Core v3" doesn't mean anything. The meaning only comes from stating compliance with a domain specification, or a specific set of the core specifications. e.g. A server could say they are "compliant with OSLC Change Management v3", and that spec hopefully defines which subset of the Core capabilities are required in which contexts/for which resources; or a server could say that they are "compliant with LDPCs, OSLC Core Resource Previews and OSLC Core Delegated Dialogs for creation, for resources of type X" (where there may be no domain specification for resources of type X).

This reduces the burden on the servers having to implement capabilities that aren't needed in their situation. Interoperability can be gained at the coarse (but meaningful) level of domain specifications, or at the fine-grained (but harder to work with) level of individual Core specs.

Clients can then say which capabilities they require from servers for each of their features - it is possible that some of a client's features may work with a server that doesn't comply with all of the capabilities required by the client, but some other features may not - this might be perfectly acceptable to a user who only wants those first features.

If other members of the TC agree with me, we should probably write up something on how servers state exactly what it is that they are compliant with (which could be part of the discovery spec), and how clients state what it is that they require from servers (which can only really go in user documentation, I don't think we have any existing place to put a machine-readable version of this).


Martin




From:        Jim Amsden <jamsden@us.ibm.com>
To:        oslc-core@lists.oasis-open.org
Date:        08/04/2015 19:44
Subject:        [oslc-core] OSLC Core in whole and in part
Sent by:        <oslc-core@lists.oasis-open.org>




During a discussion today, a question was raised about the meaning of the different OSLC Core specifications. 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.


Perhaps we should include this as a discussion item for the next meeting?



Jim Amsden, Senior Technical Staff Member

OSLC and Linked Lifecycle Data

919-525-6575


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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