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

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

Martin, I agree with your last paragraph. The only constraints (read-only or otherwise) the OSLC standards should specify are they ones that are required to enable interoperability and integration. When at all possible, servers should be able to choose who is allowed to change what. In the case of OSLC discovery, servers might make the LDPCs and SPCs read-only because the server has a fixed set of services, or how it discovers those services is computed dynamically and cannot be directly set. However other servers might choose to allow administrators to configure what services they provide if they can support dynamically added OSLC domains.

Perhaps you would like to propose something for a vote this week?


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