Fix conformance class table and broken links

[cportele]

Closes #821

[ranchodeluxe]

Thanks for doing this @cportele

I must be missing something about the semantics of 404 links for OGC specs. None of the updated links resolve either. They all 404. Do i have this right? Is this intended?

[cportele]

@ranchodeluxe - Could you clarify which links?

In general, the document links resolve, e.g. the anchor rc_filter in https://docs.ogc.org/DRAFTS/19-079r1.html#rc_filter. I noticed a few exceptions, which should be fixed, when the pull request gets merged.

Then there are the specification URIs, which are mainly identifiers and which will only resolved once the specification has been approved and is published. To avoid confusion, I have updated them, so that they appear as "non-clickable" URIs in the document.

[ranchodeluxe]

Then there are the specification URIs, which are mainly identifiers and which will only resolved once the specification has been approved and is published

@cportele thanks. This (👆) is the context I've been missing -- they are supposed to 404 until the spec has been approved. Not sure this is in your wheelhouse, but there's a similar issue I filed at ogcapi-common. However, I believe those conformance spec links used to exist already since it was approved? Or is this the same thing?

Part of the strangeness for me is that the spec talks about having a landing page with a /conformance page that should list which OGC specs it adheres to. But they're hard to list if they haven't been approved. Maybe I'll point to the drafts URLs on our /conformance page (if those exist)

[cportele]

@ranchodeluxe

However, I believe those conformance spec links used to exist already since it was approved? Or is this the same thing?

Common Part 2 is in an early phase, so it is the same thing.

Part of the strangeness for me is that the spec talks about having a landing page with a /conformance page that should list which OGC specs it adheres to. But they're hard to list if they haven't been approved.

Yes, that is an open issue. Listing a version 1.0 URI can be misleading when implementing a draft, since version 1.0 can and in general will differ from draft versions. In our implementation (ldproxy) we currently use 0.0 as the version for standards that are not draft for this reason. This is not optimal. I proposed some time ago that we would use explicit draft versions (e.g. 0.1, 0.2, etc.) also in the URIs, but that did not get much traction and typically OGC drafts include the 1.0 URIs through all draft stages. Maybe we should use this approach, which is already used in JSON-FG, for future OGC API Features drafts, too. They still won't resolve though, since OGC only wants to register URIs for approved standards.

[ranchodeluxe]

@cportele

Yes, that is an open issue. Listing a version 1.0 URI can be misleading when implementing a draft, since version 1.0 can and in general will differ from draft versions. In our implementation (ldproxy) we currently use 0.0 as the version for standards that are not draft for this reason. This is not optimal. I proposed some time ago that we would use explicit draft versions (e.g. 0.1, 0.2, etc.) also in the URIs, but that did not get much traction and typically OGC drafts include the 1.0 URIs through all draft stages. Maybe we should use this approach, which is already used in JSON-FG, for future OGC API Features drafts, too. They still won't resolve though, since OGC only wants to register URIs for approved standards.

Thanks for all the help and explanation on this 🚀 Hope those versioning discussions continue and gain traction.

They still won't resolve though, since OGC only wants to register URIs for approved standards.

About this ☝️ particular topic. I thought I'd give some end user feedback that might someday bubble to the right OGC folks:

1. When a standards org provides self-referential links that 404 it's a bad look all around
2. End users are gonna be confused. OGC is basically embedding extra meaning into a 404 against the domain "http://www.opengis.net". I don't see many end users coming to a conclusions themselves: "oh, i see, this must mean the spec is not an approved standard yet"
3. Since the goal is to use redirects I hope OGC changes their decision about which URIs they want to register. If they did register draft URIs that were versioned then redirects from "http://www.opengis.net" would handle all this logic and the end user doesn't need to understand the extra meaning of specific HTTP statuses. IMHO an improvement like this would 1) never 404 and 2) would always take you to the most recent draft version if the spec is not approved yet or take you to the approved standard

Thanks again

[cportele]

@ranchodeluxe - thanks, I agree.

cc @ghobona @ogcscotts - please have a look at the last comments.