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

Nice analysis, thanks.

What you described is that essentially servers will describe the capabilities they provide and clients will request the services the need, and it will be up to the client to do the discovery and matching on an as need basis. This is a typical supply/demand scenario driven by the demand side. It is fundamental to service-oriented architectures that match the goals, needs and expectations of consumers with the value propositions, capabilities and commitments of providers.

For this to work, it will be necessary for servers to fully describe what they provide and clients to fully specify what they need. The current OSLC 3.0 Core specification does not provide a single endpoint for doing this metadata discovery, rather it is distributed over individual resources through OPTIONS headers. This may require clients to make multiple requests to establish the capabilities they need, and gives them an opportunity to adapt their behavior to different server capabilities. This may be extra cost for clients. But the flexibility and openness that results, and the reduction in the number of usage scenarios that need to be standardized may be well worth that extra cost.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

From:        Martin P Pain <martinpain@uk.ibm.com>
To:        Jim Amsden/Raleigh/IBM@IBMUS
Cc:        oslc-core@lists.oasis-open.org
Date:        04/09/2015 03:16 AM
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).


Jim Amsden <jamsden@us.ibm.com>
08/04/2015 19:44
[oslc-core] OSLC Core in whole and in part
Sent by:        

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


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]