Discourage use of unknown epub:type values?

[mattgarrish]

The following statement is made to allow unknown unprefixed values:

Unprefixed terms that are not part of the [EPUB-SSV] MAY be used, but reading systems have no obligations to support them.

But reading systems already have no obligation to support any values used in the epub:type attribute, even those in the SSV, per the processing rules in 2.4.1.4.[1] The statement made me have to go and double-check this was still true, as it seems to be a counterpoint to the ones in the SSV being supported.

Perhaps what we might want to say here is:

Unprefixed terms that are not part of the [EPUB-SSV] MAY be included, but their use is discouraged. The use of prefixes is the preferred method for adding custom semantics.

This would still side-step the validation problem without suggesting we want people to start overloading the attribute with their own creations, particularly if we're doing this primarily to avoid validation issues arising as we tweak the SSV and can't get epubcheck deployed quickly.

[1] https://w3c.github.io/publ-epub-revision/epub32/spec/epub-contentdocs.html#sec-contentdocs-semantic-inflection-processing-reqs

[murata2makoto]

I would propose:

Unprefixed terems not defined in the [EPUB-SSV] SHALL NOT be used.

[dauwhe]

I would propose:

Unprefixed terems not defined in the [EPUB-SSV] SHALL NOT be used.

We have real-life problems with books failing validation because of differing interpretations of the changing SSV. Given that these terms almost never have actual behaviours associated with them, restricting the vocabulary doesn't make sense. I'm fine with encouraging the use of prefixed terms, but "SHALL NOT" feels much too strong, and seems to undo the change we adopted.

[mattgarrish]

Yes, "shall not" takes us back to the problem we were trying to solve by this change. I'm still uneasy about taking out conformance from a validation perspective, but I understand the rationale for why it will help in the long run.

It's also why I'm suggesting dropping in some kind of weak discouragement. It would give better justification for epubcheck emitting some kind of informative message about terms that don't match anything in the SSV. We could do that regardless, of course, but with discouragement we can point to the spec and say this is why we still provide some validation.

But if no one thinks it matters what goes in epub:type anymore, and we shouldn't validate at all, I'm fine just dropping the bit about RSes not having to support them.

[murata2makoto]

I am aware that some real-life documents specify terms not defined in the SSV. But if we allow such terms, we will be partly responsible for all future problems caused by them. If we disallow them, some people might neverthess use them but we are not responsible for any future problems.

[mattgarrish]

I am aware that some real-life documents specify terms not defined in the SSV.

That's not so much the issue as we tend to change/add to the SSV with each revision, and then those changes take time to propagate out to vendors ingestion systems. In the meantime, epubcheck will say to use the new semantic(s) when authors check locally, while the vendor systems will reject the semantic(s). Similar to the reserved prefix problem, but one we can solve by being less strict.

My concern isn't with unknown terms kicking around in reading systems, as that's harmless enough as there is so little use of them, but whether there are publishers using epub:type internally in workflows who have come to expect epubcheck to report problems. That's part of why epub:type was minted, and while I don't think it's an issue we should try to solve in new versions of epub/wpub, epub 3 came with this expectation that the attribute could be used for this purpose. Hopefully, anyone who might have created a workflow that uses the attribute has seen this change and is okay with it.

[laudrain]

Our Hachette Livre worflow in France relies on SSV values of epub:type.
I'm ok with looseness of validation in 3.2 and epubcheck. We will reinforce our own internal validation.
BTW, we use epub:type to check a11y role attributes being present in the EPUB.

[mattgarrish]

@laudrain would you want information on unknown values in informative output from epubcheck, though?

That's what I'm questioning here, as we're assuming that vendors are going to implement the new epubcheck in a timely fashion, which hasn't been the experience. I don't personally care what people put in epub:type, but might it still help to have some information of what used to be expected so we don't just create a new problem?

If we don't discourage, perhaps we should add a note that this is a significant change from earlier versions and authors should only branch out on their own with caution?

[laudrain]

@laudrain would you want information on unknown values in informative output from epubcheck, though?
It would be a good thing for EPUB producers.
An yes to "a note that this is a significant change from earlier versions"

[dauwhe]

Fixed via #1190