Clearer specification of the address attribute of <station/>, <dataselect/>, <wfcatalog/>, <availability/>

[kaestli]

The manual says: "To provide the URL(s) where a client can request information to a service for a specific stream and in a particular time window."
What does the address actually indicate? The address of the service or the address of the method?

looking at examples and practice, typically an address of a method is given:
<ns0:route networkCode="4R" stationCode="" locationCode="" streamCode="*">
<ns0:station address="https://geofon.gfz.de/fdsnws/station/1/**query**" priority="1" start="2022-01-01T00:00:00" end="2027-12-31T00:00:00"/>
<ns0:wfcatalog address="https://geofon.gfz.de/eidaws/wfcatalog/1/query" priority="1" start="2022-01-01T00:00:00" end="2027-12-31T00:00:00"/>
<ns0:dataselect address="https://geofon.gfz.de/fdsnws/dataselect/1/query" priority="1" start="2022-01-01T00:00:00" end="2027-12-31T00:00:00"/>
<ns0:availability address="https://geofon.gfz.de/fdsnws/availability/1/query" priority="1" start="2022-01-01T00:00:00" end="2027-12-31T00:00:00"/>
</ns0:route>

However, the application is sloppy: typically, the path to the query service is given, although the data (or parts of the data) is available only under the queryauth method . In other cases (seen in the wild for dataselect and availability) routing indicates the method where data is actually available, including addresses to queryauth
so the user may have excplicit method addresses, which however, cannot be fully trusted. (S)he would have to know, that there are two methods, and data may not be available at the indicated one, but the other.

I think there are actually practical reasons not to be precise on the method in the routing: you would not like to change routes when data openness changes, but the technical infrastructure hosting it remains the same.

Thus, in order not to be misleading, I'd suggest to specify that the address indicated is the base address of the service including version , e.g. https://geofon.gfz.de/fdsnws/station/1/ , where the /fdsnws/station/1/ part indicates the specification of the service, and based on that, the user shall use prior knowledge of the service specification (and, potentially, the data) to decide which method to use.

(this proposal is based on practical experience in the federator, dealing with duplicate query/queryauth routes and inconsistent handling of method URLs: using as given or reconstructing from service subsection and prior knowledge)