Open mjacoby opened 8 years ago
It looks like Whiskers isn't normalizing the URLs by combining the absolute URL from the @iot.selfLink
with the relative URL in the navigation link. I will open an issue on Whiskers to address this.
Thanks for the catch! I will talk to the spec writing team and see if they can clarify the usage of relative and absolute URLs, as there seem to be some implementation variations.
I talked with Dr. Steve Liang about the spec and it was updated to specify that navigation links can be specified using relative links or absolute links. Which version of the specification are you using?
The relative and absolute link was discussed in March 2016 at the SWG meeting at DC OGC TC. Absolute path was added. The final specification will include that. The specification will be published soon. It has been submitted to OGC.
Thanks for the clarification. We are currently using the specification in version 1.0, internal reference number 15-078r4 from 26.10.2015.
So does the new version of the specification allow for relative and absolute navigation links? If yes, this will still be a bug (of Whiskers). Is the new version of the specification available somewhere or can you tell me when it will be available.
The final spec is in OGC's hand now. It will be published anytime. Or you can download from OGC portal: https://portal.opengeospatial.org/files/?artifact_id=69587
@mjacoby Is there any information you can share regarding your STA implementation? A test link or web site?
@liangsteve We are currently working on a STA implementation and plan to release the first version for testing purposes as open source within the next weeks.
It looks like Whiskers isn't normalizing the URLs by combining the absolute URL from the @iot.selfLink with the relative URL in the navigation link. I will open an issue on Whiskers to address this.
Relative to the @iot.selfLink, or relative to the url used to retrieve the document? The standard does not specify. So far I assumed relative to the url used to retrieve the document, like in html. Relative to the selfLink is a lot easier to implement though, so that also sounds sensible.
Should probably be explicitly specified in the standard either way.
It's relative to the url used to retrieve the document.
When running the dashboard against another implementation of the SensorThings API than the two provided which gives relative URLs for the @iot.navigationLink properties (like defined in the standard) the thing view crashes with the error
app.js [sm]:22 Uncaught TypeError: Cannot read property 'map' of undefined
because the relative URL of the navigationLink is resolved to the base urlhttp://localhost:4200/
.This seems to be caused by the usage of the Eclipse Whiskers module where there is actually a file (called
backend.js
) that stores a base URL for a SensorThings API server but it is not used when expanding the datastreams of a thing.