-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Templated links conflict with OGC API - Common?! #275
Comments
@m-mohr I think you are right. I will create a PR to modify the definition of templated links accordingly as a basis for futher discussion in the SWG. |
We discussed this is the SWG extensively and it was decided that because of the need to still access old-style OGC web services we needed templated links in the core ... since those old-style services require all kinds of parameters in order to create a resolvable URL (e.g. request=, service=, version=, layers=, etc.). |
I see the argument, but it is more complex than that. The original design came from the Vector Tiles Pilot which followed the approach in HAL. See also this issue. OGC API Tiles eventually added the So, I think that Common is what has to be updated. |
@cportele oh crap! That means that I should probable update records to use the I think @m-mohr has it right. Just my $0.25 worth ... but that still leave open what I should do in records. I guess, since it is already being used in tiles I should adopt the Sigh! |
Thanks for the comments. Just my 2cts:
|
As I said, I see the point that a client expecting a de-referenceable URI in But there was the decision some years ago to follow the HAL practice to use a If we think this is an error, then this should be discussed quickly (probably in the session tomorrow) so that a different approach is agreed for Records, Features, etc. But at least for the two standards OGC API Tiles and OGC Two Dimensional Tile Matrix Set and Tile Set Metadata it is too late anyhow. |
@cportele I was planning to make this an agenda item in the Records portion tomorrow since this is cross cutting and we need a quick discussion and decision. |
It's impossible to oversee all OGC APIs so it's difficult if an APIs imply changes to other APIs. I see myself pretty close to various OGC APIs, but I've just discovered this recently, I assume others that are less close to it, would only find it even later. I also assume others don't see this as a big issue if they don't have a lot of existing implementations like STAC has. And I'm biased of course towards STAC. When is the session tomorrow? I'm not on location, but could try to join the discussion remotely. Thanks Peter for making this an agenda item. |
Records starts at 11:15am Huntsville time. |
Thanks. I have a conflict, sorry. But I think I made the point clear enough here. Hope for a fruitful discussion tomorrow. |
07-AUG-2023: Pinged @ghobona for a status update. In the meantime another option was proposed for discussion when we discuss this in the bigger group (see here: #290 (comment)). |
@pvretano I think the issue should be discussed and resolved within the OGC API - Common SWG. There is a GitHub Issue on the topic or similar at opengeospatial/ogcapi-common#187 |
30-OCT-2023: The Architecture DWG has its meeting and the concensus was to use a separate "templatedLinks" section as we have done in PR #290. @pvretano will update the PR to make sure that the link tempate object match the draft Link Temaplte RFCs (its for headers but we can adopt for JSON objects). https://github.com/ietf-wg-httpapi/link-template |
In OGC API - Records I recently found the chapters about "Templated links with variables":
I think the addition of templates links with variables is not correctly extending OGC API - Common and is actually in conflict with it (also with STAC).
If I understand Common, ch. 6.3 correctly, the href must be a valid IRI/URI according to RFC 8288.
This implies to me that with a client, all
href
s should be resolvable and if I render them e.g. in a HTML document ashref
parameter in ana
tag, user can click the link without issues and end up at a "valdid" page.The way Records adds templated links, I think this would break clients that are not aware of templated links. If I understand correctly, that
templated
must be set totrue
and thenhref
is containing variables. As such thehref
won't resolve without specifying the values for the variables and my HTML example with thea
tag won't work anymore.A simplified example from Records:
The href as such doesn't work in a naive (non-template-aware) client. The
templated
property basically weakens the href requirements, which is basically against the Liskov Substitution Principle.I think Records has to extend Common in a different way. It must provide a default href that works (with defaults for the variables) and then add variables on top for clients that are aware of this functionality.
It could look like this for example:
In addition to all this, are templates variables really needed in the core?
The text was updated successfully, but these errors were encountered: