[OASIS Issue Tracker] (OSLCCORE-50) Should we omit the "read-only" values in the discovery resource shapes?

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

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

Martin Pain commented on OSLCCORE-50:
-------------------------------------

I'm not suggesting introducing a new value, I'm suggesting omitting that triple from each of the resource shapes for the discovery resources. The resource shape for oslc:Property, in v2, allows for zero oslc:readOnly properties on an oslc:Property.
However, that resource shape also says "If omitted, or set to false, then the property is writable." which goes against RDF's "open world assumption". (If omitted it should mean nothing - that it hasn't been stated whether it is writable or not. Although clients then have no choice but to try writing, and see if it fails - which is actually the same situation they have when it is set to true. So ignore my "open world assumption" point.)

One thing I didn't take into account when opening this ticket was that in v2 we say against oslc:readOnly "Providers SHOULD declare a property read-only when changes to the value of that property will not be accepted after the resource has been created, e.g. on PUT/PATCH requests." - I didn't realise that initial creation was not covered by oslc:readOnly.

> Should we omit the "read-only" values in the discovery resource shapes?
> -----------------------------------------------------------------------
>
>                 Key: OSLCCORE-50
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-50
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Martin Pain
>            Assignee: James Amsden
>            Priority: Minor
>
> This was the case in v2 (so perhaps we can defer this), but I don't see why we set "read-only" to true for these properties. I would have thought some servers might allow clients to create new ServiceProviders, or modify ones they previously created. e.g. a generic ServiceProviderCatalog server that acts as a registry of other servers. I'd suggest we have read-only as not specified (if that won't be problematic), but this is probably too big a thing to consider at this stage. It's not really causing a problem.
> (Note: dcterms:identifier on oslc:Publusher - §A.6 - has an "unspecified" read-only value. Should it be consistent with the others?)



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