oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: OR semantics of applicable shapes for oslc:resourceShape
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: "OASIS OSLC Core TC Discussion List (oslc-core@lists.oasis-open.org)" <oslc-core@lists.oasis-open.org>
- Date: Thu, 3 Mar 2016 16:34:36 -0500
On today's Core TC call, we discussed a
resolution to OSLCCORE-44
oslc:instanceShape should explicitly allow multiple valuesby simply adding a sentence to the end of the oslc:instanceShape Property
indicating a resource may be associated with zero or more shapes.
But this uncovered another possible
issue with the meaning of applicable shapes. The second to the last paragraph
in section 6.2 says:
"If more than
one shape applies to a resource then that resource SHOULD satisfy
all the constraints defined by all the shapes (AND semantics). However,
the specification for a service description MAY define alternate
semantics. For example, a service MAY require that the resource
satisfy the constraints defined by at least one of the shapes (OR semantics).
"
This results from a different meaning
of the different ways shapes are associated with resources:
1. oslc:instanceShape - directly associates
a constraining shape with a resource
2. oslc:resourceShape - associates a
constraining shpae with the entity request or response resource of a service
3. oslc:valueShape - associates a constraining
shape with the resource that is the object value of a property of a resource
The introduction of OR semantics might
be because of some confusion caused by the way oslc:resourceShape is described.
In the description above, the shape is applicable to the resource produced
or consumed by the service. However, the oslc:resourceShape Property section
describes oslc:resourceShape as "used to link
an application service description with a shape resource that describes
some aspect of the service's API contract",
describing the resources involved in the service, not constraining the
actual resources. This perspective is implicitly OR semantics since the
service might describe more than one resource.
This could be an unfortunate coupling
of the idea of applicable constraints on a resource, and descriptions of
resources involved in a service. These don't seem like the same thing.
I suggest the easiest way to resolve
this is to simply remove "However, the specification
for a service description MAY define alternate semantics. For example,
a service MAY require that the resource satisfy the constraints
defined by at least one of the shapes (OR semantics)."
from the second to the last paragraph in section 6.2.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]