search

w3c / epubcheck

The conformance checker for EPUB publications
https://www.w3.org/publishing/epubcheck/
BSD 3-Clause "New" or "Revised" License
1.63k stars 403 forks source link

CFI Validation #150

Open rdeltour opened 10 years ago

rdeltour commented 10 years ago

From markus.g...@gmail.com on December 22, 2011 11:31:34

Add validation of CFI links: a) syntactical validity b) resolve

Original issue: http://code.google.com/p/epubcheck/issues/detail?id=150

mattgarrish commented 5 years ago

I'm not sure this issue matters anymore. We've removed required support for authored epubcfi in 3.2, as it's unlikely they'll ever be used except by reading systems. I'd propose closing it.

rdeltour commented 5 years ago

We've removed required support for authored epubcfi in 3.2

Yes, I agree. Let's close as wontfix

rdeltour commented 5 years ago

well, maybe I was too quick in closing this: what should we do if we encounter CFIs in a publication however? If they're accepted, then it would make sense to validate them? I don't remember what 3.2 says about that.

mattgarrish commented 5 years ago

what should we do if we encounter CFIs in a publication however?

But what's the reality of that ever happening in a content document at this point? That's why support for authored CFIs was dropped, as reading systems aren't supporting them and there's no apparent likelihood of that changing.

There are only two places left I can think of where a CFI might be encountered during validation:

If you want to tie this to realizing support for either of those, then it might make sense, but they're both also far from being realities. It'd be a really, really, really low priority, I suspect. (I'm personally not holding out hope that the satellite specs have much of a future anymore.)

rdeltour commented 5 years ago

Yes, I definitely agree with you on the state of things.

Unfortunately EpubCheck is used by almost everyone as a strict validator and not as a linter. In other words, its goal is not to report nonsensical content but just non-conforming content.

I would argue it would be more useful to actually warn about the presence of CFI links, but if it's not a SHOULD NOT in the spec then unfortunately we can't do that.

I'm leaning towards introducing a "soft" warning (a USAGE or INFO message) saying that CFI were detected and will not be checked further. That way, it serves both as a warning for no-longer-supported CFIs, and as an information on our non-validation of CFIs. WDYT?

mattgarrish commented 5 years ago

saying that CFI were detected and will not be checked further

Right, we shouldn't add any language that isn't in the specification (like use being discouraged, when the spec is just completely silent on them), so noting and bailing out on verifying seems like a good direction for handling them.

larscwallin commented 5 years ago

Hi guys, We (Colibrio) are planning to propose support for EPUBCFI's in Media Overlays. This would be a very helpful addition to the "talking book" aspect of EPUB production / post-production as it would make it possible to add narration etc to existing publications without modifying their content markup. I know we should have been vocal during the 3.2 process but better late than never right.

We have made a TypeScript EPUBCFI parser with validation built in which we are offering as open source to help reading systems and web annotation servers offer support for EPUBCFI's. We have not had time to put it on GitHub yet but it is on its way. If you want to use it in EpubCheck i will speed this up.

danielweck commented 11 months ago

Hi @larscwallin

We have made a TypeScript EPUBCFI parser with validation built in which we are offering as open source to help reading systems and web annotation servers offer support for EPUBCFI's. We have not had time to put it on GitHub yet but it is on its way.

Is your CFI code now open-source? (parser + generator?)

I'm gathering information about existing JS/TS implementations (various degrees of correctness / test coverage):

Thank you! Daniel

larscwallin commented 11 months ago

Hi Daniel 🙂

We never had time to do the Open Source dist. Let me take it up with Andreas again. We really want it Open Sourced.

I'll get back to you asap 👍

Hope to see you soon again 😊 Lars

On Mon, 25 Sept 2023 at 17:46, Daniel Weck @.***> wrote:

Hi @larscwallin https://github.com/larscwallin

We have made a TypeScript EPUBCFI parser with validation built in which we are offering as open source to help reading systems and web annotation servers offer support for EPUBCFI's. We have not had time to put it on GitHub yet but it is on its way.

Is your CFI code now open-source? (parser + generator?)

I'm gathering information about existing JS/TS implementations (various degrees of correctness / test coverage):

Thank you! Daniel

— Reply to this email directly, view it on GitHub https://github.com/w3c/epubcheck/issues/150#issuecomment-1734007295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTDP7W7X2U4ZHBO3HV3QDX4GRNFANCNFSM4AIYXGHQ . You are receiving this because you were mentioned.Message ID: @.***>