[OASIS Issue Tracker] (OSLCCORE-61) Conjunctive vs. Disjunctive semantics for multiple applicable shapes

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62083#comment-62083 ] 

Nick Crossley commented on OSLCCORE-61:
---------------------------------------

I like the new alternative proposal.

> Conjunctive vs. Disjunctive semantics for multiple applicable shapes
> --------------------------------------------------------------------
>
>                 Key: OSLCCORE-61
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-61
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>            Priority: Minor
>
>  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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)