[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=61470#comment-61470 ] 

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

We could go one of two ways:

As Jim suggested, changing it to "read-only: false", and let servers reject a write to those properties if they want to.

Or, we could leave it as "read-only: true", and let servers accept a write to those properties if they want to.

Neither of these approaches allow servers to advertise whether they accept writes to those properties or not. And if they tried to do so by defining their own resource shape, the clients would end up with conflicting information: one shape says true, the other says false. (And that is the same whichever decision we make). And we don't provide (and I don't think we want to provide) any way to resolve such conflicts.

So I no longer see any value in changing these to "read-only: false", especially as I expect in the majority of cases they will be read-only. (I only saw value in changing them to "read-only: unspecified", but that was before I realised that that implies "read-only: false".)

Actually, if we did leave it as "read-only: unspecified" (implying "read-only: false") in our shapes, and servers defined their own shapes with "read-only: true", then there wouldn't be any RDF triples that conflicted, but the semantics of the resource shapes taken individually would conflict. (This is the problem with breaking the open world assumption - ask me if anyone wants me to explain my thinking & understanding on this thought process). But I think that just makes things worse so, as discussed before, leaving them as unspecified doesn't help.

> 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)