Open KhronosWebservices opened 3 years ago
Is it worth touching the 0.90? I don't really want to give those pages more google juice by updating them.
What tool did you use for these reports? I once found a good one but then promptly lost it again.
The vulkan links are easy to fix, I didn't realize we were somehow using an attribute for them, I just added it to the build script. The flag bits ones are a bit harder.
I'll have a bunch of these fixed in the shortly-upcoming release.
a bunch of the 0.90 ones can be fixed by making a permanent redirect from https://www.khronos.org/registry/OpenXR/specs/0.90/openxr.html to https://www.khronos.org/registry/OpenXR/specs/0.90/xrspec.html . Can I put an htaccess file in here and have it work?
Should be fine to add an .htaccess file.
can you check and see if it worked? I can't load any 0.90 ref pages now
ok, can't load anything in 0.90 now. I think the htaccess files broke it.
I reverted my htaccess changes.
Should most likely be something like
RewriteEngine On
RewriteRule ^openxr.html$ https://www.khronos.org/registry/OpenXR/specs/0.90/html/xrspec.html [L,R=301]
the 1.0 contents of this repo are updated, you can re-scan and see what we have left - think a couple of all-caps defines mostly
What tool did you use for these reports? I once found a good one but then promptly lost it again.
Using Website Auditor (https://www.link-assistant.com/website-auditor/), which has been consistently reliable.
the 1.0 contents of this repo are updated, you can re-scan and see what we have left - think a couple of all-caps defines mostly
Quite a few broken 1.0 links remain:
OK, that matches what I expected. The FlagBits is because of a bad choice we made earlier, I'll fix it but it will take a little longer. The all-caps defines also basically just need a ref page added for them, right now they're all in a single table per "type" (platform, graphics API). I fixed as many as I could last night without making any spec changes I would have wanted to get wg approval for, basically :)
BTW, I've been looking at similar issues since James brought up the report for the Vulkan registry. There are a bunch of causes in our case including the refpage extractor generating the wrong link macro for some Flags types in the auto-See Alsos, which was trivially fixed. Something I'm working through is writing a Ruby generator to bring relevant parts of the API description inside the link macros like flink:, and use that to validate the macro link targets at build time, which is especially helpful for us because we build the spec with many different combinations of core versions and extensions. Probably less helpful for you.
I'm not sure how much if any of what I'm working on is applicable, but I have been intending to do another sync pass on the Vulkan / XR scripts anyway, hopefully within a few weeks.
Also, the internal links are trivial to check in the generated HTML without running a link-checker on the website - this find almost all of the problems for us without publishing and running an external tool. There is scripts/check_html_xrefs.py in the Vulkan repo for this.
The following Page(s) have broken Link(s):