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
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: Jim Amsden <jamsden@us.ibm.com>
- Date: Thu, 9 Apr 2015 08:16:24 +0100
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]