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

James Amsden commented on OSLCCORE-50:
--------------------------------------

The TC agreed that we will not change the meaning of readOnly: that leaving read-only unspecified defaults to false, not unspecified and servers can choose.

Regarding the issue raised here: that specifying readOnly: true for most ServiceProvider and ServiceProperties inhibits server flexibility in allowing changes to available services:

The fact that these properties are readOnly is in the context of these resource representations. That is, a client cannot update a ServiceProvider resource and expect to be able to use PUT to add new services or even new domains. However that does not prevent the server from providing other means of configuring its capabilities that are then reflected in readOnly properties in an updated ServiceProvider resource. For example, a server could provide a means of specifying a config.json files that describes its capabilities and uses environment variables to choose the desired config.json file for different contexts (development, testing, production, etc.). The server could read the configuration information at startup and configure its LDPCs. Once the server is running, the properties on the LDPCs would be readOnly and the ServiceProvider resource might be dynamically constructed from the LDPC properties.

For another example, a server could provide a mechanism to support plugins that allowed users to specify domains and ServiceProviders at runtime. The server would update the LDPCs accordingly and their OSLC properties would be readOnly until some other plugin was added or removed.


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