Uploaded image for project: 'OASIS OSLC Lifecycle Integration Core (OSLC Core) TC'
  1. OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
  2. OSLCCORE-50

Should we omit the "read-only" values in the discovery resource shapes?

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: None
    • Labels:
      None
    • Proposal:
      Hide

      We change "true" to "unspecified" for all properties on all discovery resource shapes - leaving the decision up to the implementations.

      The TC discussed this and thought it could create some compatibility issues. We decided to include section 5.2 Updating Discovery Information in discover.html to indicate that servers may provide other means of updating their configurations that are reflected in the service provider discovery resources with read-only values. That means clients can't use PUT of service provider discovery resources to reconfigure a server, but servers could provide other means.

      Show
      We change "true" to "unspecified" for all properties on all discovery resource shapes - leaving the decision up to the implementations. The TC discussed this and thought it could create some compatibility issues. We decided to include section 5.2 Updating Discovery Information in discover.html to indicate that servers may provide other means of updating their configurations that are reflected in the service provider discovery resources with read-only values. That means clients can't use PUT of service provider discovery resources to reconfigure a server, but servers could provide other means.

      Description

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

        Attachments

          Activity

            People

            • Assignee:
              jamsden James Amsden
              Reporter:
              martinpain Martin Pain
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: