OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

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

Re "What specific properties do you think are at issue? ":

Potentially "oslc:ServiceProviderCatalog oslc:serviceProvider", but if SPCs are LDPCs then you could add a new service provider (or delete an existing one) by using POST (or DELETE, respectively) without having to do a PUT/PATCH on the SPC, so that's not really an issue.

Similarly with "oslc:ServiceProvier oslc:Service".

However, the other properties on oslc:ServiceProvider, oslc:Service and their inlined resources are at issue. My thought was that if one server is hosting the SPC, and other providers are POSTing their details to that SPC (so clients only have to look in one place and get discovery details for multiple servers) then those other providers will need to update the details that they POSTed. However, looking at it again, they could add a link from the SPC to an SP on their own server, and that would avoid the issue. (As SPs don't have to be inlined in SPCs).

Another use case would be that servers could allow clients who have certain permissions to rename ServiceProviders via a PATCH on the oslc:ServiceProvider resource. Our resource shape is unnecessarily saying that that isn't allowed. But this is more a conceptual point rather than anything important. (They can still allow it even if the shape says it isn't allowed.)

I think it would be better not to specify an oslc:readOnly property in the discovery resources (possibly in any of our shapes) except where there a specific reason for a specific property. But I'm happy to close this ticket as it's a change from v2 and not a big issue.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]