Create sub-assertions for Keywords in the Links section

[mlagally]

Link types and media type tables:

Keyword	Type	Constraint
href	IRI of the link target	mandatory,anyURI
type	media type [RFC2046] of the link target	mandatory, the supported set of media types is defined in Media Types for Link Targets below.
rel	link relation type IANA Link Relations	mandatory, the supported subset of relation types is described in Link Relation Types below.
sizes	string with icon dimensions	mandatory for icon link targets, forbidden otherwise.
hreflang	array of string with valid language tags according to [BCP47]	optional.

Type	Constraint
text/plain	charset=UTF-8
text/html
text/markdown	charset=UTF-8
text/pdf
application/json
application/ld+json
application/octet-stream
image/jpeg
image/png

[mmccool]

There are two parts to this: updating the markup, then updating the script to generate the implementation report based on this markup.

Basically each row of each table needs a class assigned to it. Since these tables have different formats, I propose using a different class for each table:

<tr class="rfc2119-link-type-assertion">...</tr>

and

<tr class="rfc2119-content-type-assertion">...</tr>

For updating the script, I will also need a "template" for the assertion to include elements from the table. Let's discuss that in these comments; the template also needs to include the appropriate RFC2119 keyword.

[mmccool]

Another option here would be to have a standard format for "constraint tables" that potentially could be applied to other tables. If we use the format of the first table, with three columns, and can add an appropriate column to the content type table, then we could use a single class like "rfc2119-constraint-assertion". But I'm ok with using different labels for different table formats.

[mmccool]

Given the associated "parent" assertion for the Link table, "The following keywords are defined for links in the HTTP profiles and MAY be present in profile-compliant TDs with the constraints defined by this section," I propose the following template for each row of the link table. Actually, I realized there are MULTIPLE assertions needed since if it exists, the type and other constraints must be satisfied. So these assertions are MUST even though the parent is a MAY:

The value of the <Keyword> attribute of links MUST have type <type> and satisfy the constraint <constraint>.

But even this is not right since even though the parent assertion says "MAY", most of the constraints have the word "mandatory" (which ideally would be in its own column, BTW), and the above sentence would not really make sense. So I'm not sure what is really needed here. If there is a separate column for "mandatory/optional" I can based the RFC2119 keyword on it.