depreciated epub:types should generate USAGE not ERROR

[nekennedy]

Currently deprecated epub:type elements are generating an error, unknown ones are generating a usage message:

ERROR(OPF-087): ./Documents/Development/Sprints/Jeremy/4_2/9781524761547.epub/OEBPS/Acho_9781524761547_epub3_c01_r1.xhtml(12,57): Property 'list' is not allowed on documents of type 'application/xhtml+xml'.
USAGE(OPF-088): ./Documents/Development/Sprints/Jeremy/4_2/9781524761547.epub/OEBPS/Acho_9781524761547_epub3_c01_r1.xhtml(15,32): Unrecognized property 'chair'.

Proposal: either make them the same, or change the deprecated property to USAGE and "Depreciated property 'XXXXX'."

[rdeltour]

Thanks @nekennedy for the feedback! 👍

ERROR(OPF-087): ./Documents/Development/Sprints/Jeremy/4_2/9781524761547.epub/OEBPS/Acho_9781524761547_epub3_c01_r1.xhtml(12,57): Property 'list' is not allowed on documents of type 'application/xhtml+xml'.

In the latest editor's draft of the Structural Semantics Vocabulary (that will be published in sync with EPUB 3.2), the "list" property is defined as not allowed in HTML (it is only defined for SMIL documents).

USAGE(OPF-088): ./Documents/Development/Sprints/Jeremy/4_2/9781524761547.epub/OEBPS/Acho_9781524761547_epub3_c01_r1.xhtml(15,32): Unrecognized property 'chair'.

Yes, this is now conforming to EPUB 3.2, which says:

Unprefixed terms that are not part of the [EPUB-SSV] MAY be included, but their use is discouraged.

deprecated epub:type elements are generating an error

I see where you're coming from, when looking at the list term… but again, these are special cases which are no longer marked as deprecated but really as not allowed. Deprecated terms (e.g. "subchapter" are now reported as WARNING.

See also the discussion in #531 and w3c/epub-specs#1222.

If you think this behavior should be reconsidered it would need to be discussed in the CG, for instance by commenting on w3c/epub-specs#1222.

For now, EPUBCheck's behavior seems to be conforming to the spec (forthcoming 3.2 vocab), so I'm closing the issue as invalid. But feel free to keep on discussing here! 😊

[mattgarrish]

The general consensus on the call today is that invalid use of epub:type doesn't warrant warning/errors. It serves no particular function beyond pop-up footnotes, so there's no value in forcing people to fix any misuses.

I misunderstood the issue a bit, as I thought this was about the terms we had marked recently as deprecated, not about the terms that are only intended for media overlays, but my impression is that the group wants them all treated the same way as usage messages.

[rdeltour]

The general consensus on the call today is that invalid use of epub:type doesn't warrant warning/errors.

Ah, sorry I wasn't on the call… So everything epub:type related becomes a USAGE, right?

What happen to generic errors like an undeclared prefix or invalid prefix declaration, they would still be reported as errors, correct?

[mattgarrish]

What happen to generic errors like an undeclared prefix or invalid prefix declaration, they would still be reported as errors, correct?

I don't think we need to go that deep into changing severity, no. If you're using those mechanisms, then you'll likely want the messages.

This issue generally focuses around not causing validation problems for the unprefixed terms in epub:type.

Correct @dauwhe @RachelComerford @TzviyaSiegman ?

[rdeltour]

would the deprecated properties other than epub:type (e.g. the deprecated records in link rel properties) would still be reported as WARNING, or do they get the same treatment?