I am a bit worried about the usage of MUST-s and SHOULD-s in this section.

Right, I have the same concern, but I was trying to harmonize this with the fact that we normatively describe what validators have to do for handling deprecated features.

Maybe we should also remove the normative keywords from the deprecated features section and keep all talk of validators informative?

@iherman

I am a bit worried about the usage of MUST-s and SHOULD-s in this section. Do we really think this section should be normative and therefore warrant these terms?

I thought the point of this section was to justify using EPUBCheck for CR? If yes then we need it to be normative, no?

@mattgarrish
I too was originally confused by "requirements" vs. "recommendations". These are not defined anywhere as far as I can tell, specifically, not in RFC2119.

Does this section need to discuss severity at all?

What about using only something very generic along the lines of what is said in HTML:

Conformance checkers must verify that a document conforms to the applicable conformance criteria described in this specification.

and then precise that they checking scripts is optional.

These are not defined anywhere as far as I can tell, specifically, not in RFC2119.

I'd argue they're implicit in the definitions. A MUST is a requirement of its specification as are it's synonym (REQUIRED) and negative (MUST NOT).

But we can, of course, make this explicit.

I'd argue they're implicit in the definitions.

Yeah, it's too confusing IMO. Also, "requirements" is often use to encompass them all. For example, RFC2119 talks about varying "requirement levels", so RECOMMENDED is one specific requirement level 🙃. Another example is our own section titles ("XHTML Requirements"), or when we say things like "This specification defines the authoring requirements for EPUB Publications".

I would advise against using "requirements" vs. "recommendations" altogether.

But again I'm not sure why we need to make two distinct cases anyway, unless we really want to talk about severity (but then, why?).

What you're saying is basically: validator MUST report MUSTs, and SHOULD report SHOULDs.

What I'm proposing is: validator MUST check conformance, unless it's impossible to check by a machine in which case its OPTIONAL.

What about using only something very generic along the lines of what is said in HTML:

Ya, I had a look at that when I was writing the section up, but the sticking point (for me) is that we normatively say how to report the issues arising from unsupported features.

If we don't say how to report issues generally, why normatively say how to handle them there?

Once we start dropping the normative keywords we do end up back at a simpler statement like HTML makes, but it also suggests validators are outside the scope of the specification.

@iherman

I am a bit worried about the usage of MUST-s and SHOULD-s in this section. Do we really think this section should be normative and therefore warrant these terms?

I thought the point of this section was to justify using EPUBCheck for CR? If yes then we need it to be normative, no?

I do not think that is necessarily a conclusion.

If we define, normatively, the behaviour of an EPUB Validator, then we have to test that as part of CR. Ie, we have to test whether EPUBCheck is a conformant validator in CR, when we use EPUBCheck as a validator for CR... this is kind of a circular argument that I am not sure how to solve.

I do not see any issue if the full section is non-normative, setting informal expectation (and I believe having that section is a great idea!) and we rely on the community usage of EPUBCheck as part of the CR process.

If we define, normatively, the behaviour of an EPUB Validator, then we have to test that as part of CR.

Ya, this is what really worries me. We want epubcheck as a proof without it being subject to exit criteria itself.

See if the latest commit helps at all. I've made the validator section informative and rewritten it to tie it into being a proof of the enforceability of the specification requirements. I also took out the parts about reporting severity and instead tried to explain why reporting these issues is useful to authors.

I also changed the unsupported features so the statements about how to report the features are in notes.

See if the latest commit helps at all. I've made the validator section informative and rewritten it to tie it into being a proof of the enforceability of the specification requirements. I also took out the parts about reporting severity and instead tried to explain why reporting these issues is useful to authors.

I also changed the unsupported features so the statements about how to report the features are in notes.

That works for me, thank you.

TBH if this section is informative I'm not sure I understand how it improves the specification.

It doesn't define validator requirements, but straying into those was always problematic. Short of writing rules on how to report every violation, it's pointless to sprinkle the specification with a few requirements on how to report issues. Adding a few more vague normative requirements isn't making things better.

Where I see it helping is in providing a place to surface notions about validation that we know to be true but have never been voiced. That recommended practices are not violations of the specification, for example. It may change nothing in the real world, but at least it documents that it's not the specification that is the issue when content is rejected for warnings.

It also provides a place to formally point readers to epubcheck, same as you can find your way to validator.nu from HTML's section.

Not everyone who arrives at the specification is going to understand conformance checking. The latest commit rewrites the section some more to focus it more directly on authoring concerns, so there's no focus on what a conformance checker is expected to do.

Can this be merged or do we need to discuss it any more?

As there hasn't been any further comment on this for a couple of weeks, I'm going to merge. If further tweaking is necessary, we can always do in another issue.