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: Jim Amsden <jamsden@us.ibm.com>
- To: oslc-core@lists.oasis-open.org
- Date: Thu, 9 Apr 2015 11:14:35 -0400
Martin,
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
919-525-6575
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).
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]