Styles: Changes to a style with multiple occurrences in an API

[cportele]

Question from the Sprint kickoff:

If a style foo is used in several places in an API (that is, there are several resources where the path includes /styles/foo somewhere), does a PUT/DELETE on that style affect all occurrences of the style or only the one on which the operation is executed? In other words, is it only one resource with multiple URIs or are these separate resources?

[ghobona]

I can imagine a situation whereby different encodings of a portrayal specification are developed by different people at different points in time. This would require the encodings to be separate resources, perhaps associated through some declared relationship (ebRIM has association objects and SKOS has skos:related plus others) but without automated synchronisation of changes. That's just my opinion. What do others think?

Cc @joanma747 @jerstlouis @pomakis @jeffharrison

[cportele]

@ghobona - That would be a separate issue. In the Styles API, the Style is the resource, independent how many encodings are available. One can update specific encodings using PUT, but that should be done in sync since it is the same style. If different encodings are considered separate styles by a publisher and are managed separately, these are separate styles with separate URIs.

This issue is about having a "night" style at, for example, /styles/night and /collection/foo/styles/night.

[pomakis]

My view on this is that /collections/foo/styles/night is a sub-resource of /styles/night. That is, I would expect a DELETE of /collections/foo/styles/night to remove the part of the /styles/night resource that's for collection foo. A future GET of /collections/foo/styles/night would then return a 404 Not Found, whereas a future GET of /styles/night would return a style definition that lacks any mention of collection foo.

That's the way CubeWerx has implemented it anyways. I have the DELETE operation enabled at our style endpoints at "https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/Daraa". Feel free to experiment with this behaviour. If you do so, please let me know so that I can rebuild the nominal state of things once you're done.

[cportele]

@pomakis - We have not implemented it that way, but it does make sense to me, so I will update our implementation.

Our implementation currently derives the style /collection/foo/styles/night from /styles/night by removing all other collections from the style. Deleting /styles/night would delete all /collection/*/styles/night, but deleting /collection/foo/styles/night would have no effect.

[jerstlouis]

@ghobona in our implementation, the server automatically generates all encodings from a single style, so the different encodings are always in sync.

[pomakis]

I propose adding something like the following statement to the "OGC API - Styles" specification:

A service may implement HTTP PUT and/or HTTP DELETE methods for the /collections/{collectionId}/styles/{styleId} endpoints. If implemented, these methods shall have the effect of adding/replacing or deleting the definition of the specified style as it pertains to the specified collection. E.g., after a DELETE of /collections/foo/styles/night, a future GET of /collections/foo/styles/night should return a 404 Not Found, whereas a future GET of /styles/night should return a style definition that lacks any mention of collection foo.

[ghobona]

@cportele We discussed this Issue earlier today during the 'short stand up' session. The participants liked the statement proposed by @pomakis in https://github.com/opengeospatial/ogcapi-code-sprint-2021-05/issues/18#issuecomment-849843553. Let us know during the Daily Brief Back today if you would like to revise the statement or discuss it further.

[cportele]

@ghobona - I have no problem with the statement per se, but to include something normative in the spec, it needs more work, because the spec does not explicitly have normative statements about /styles or /collections/{collectionId}/styles, only about {baseResource}/styles. I.e., we need to generalize this statement and move most of the current text to informative text / an example.

[cportele]

Meeting 2021-11-02: The behaviour should be server-dependent. Servers may prohibit update or replace operations on derived styles (derived resources) in general.

This is related, but somewhat different from the case discussed in #40, which is about derived representations of the same resource.