enforce rel requirements

[mattgarrish]

This PR makes the following changes:

• it limits the contents and pagelist relations to one resource
• it adds a step to validate the relation requirements - also includes that covers should have a name and description
• I also moved the structural relations ahead of the informative relations in the spec, as I find it annoying the less important relations are listed first

But I think this needs more work as described in #143.

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Nov 3, 2019, 10:44 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 Related URL

�[33m📡 HTTP Error 520:�[39m �[36mhttps://rawcdn.githack.com/w3c/pub-manifest/3270e0d2e7300fa25afd949c636123d17de9114a/index.html�[39m

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[iherman]

Another slightly edge case (it is a matter of taste, really). It says now:

if resource["type"] contains the value "cover":
if cover is false, set cover to true and check:
    if resource["name"] is not set or is an empty string, validation error.
   if resource["description"] is not set or is an empty string, validation error.
otherwise, validation error.

I wonder whether it is not more logical to say that the 'cover' is set to true if that stuff is there and it is valid. The algorithm, as it stands now, will flag a cover page as existing even if it is not valid even if there is another one down the line that is perfectly valid.

(I do not feel strong about this...)

[mattgarrish]

I wonder whether it is not more logical to say that the 'cover' is set to true if that stuff is there and it is valid.

I'm hesitant about this, as they're only warnings. If they were stronger requirements than "should", maybe, but otherwise we're sort of ignoring that you're not supposed to list these twice and that we give precedence to the first one found.

And what if you don't find one better specified, do you have to go back to the first, or is there a formula for which is best of not perfect options?

End of the day it's an authoring mistake to have two covers as two separate resources, and incomplete information is one of the things that can go wrong. Better to warn the author and have them correct it than the user agent spend time trying to solve this, IMO.