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

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

The other option is that we specify these properties as readOnly: false and let servers accept or refuse a PUT depending on their ability. This doesn't take anything away from v2 clients, and opens the possibility of more dynamic and incremental configuration of services through a more direct update to LDPC properties.

This is what I thought Martin was originally proposing.

That is, specifying readOnly: false perhaps doesn't mean that the property is writable at any point in the server's lifecycle, just that it might be writable sometimes.

Its similar to an experience I had late one evening. I was very hungry and pulled up to a convenience store that had a big sign that said 'OPEN 24 HOURS'. But the clerk was closing up and locking the door. I said "Hey, why are you closing, the sign says OPEN 24 HOURS!?". He said "Yes, but not in a row!" (Steven Wright).

This just goes to show the flexibility of semantics.


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