CFI Validation

[rdeltour]

From [email protected] 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]

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]

We've removed required support for authored epubcfi in 3.2

Yes, I agree. Let's close as wontfix

[rdeltour]

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]

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:

• in open annotation data files
• in a rendition mapping document

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]

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]

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]

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]

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):

• https://github.com/fread-ink/epub-cfi-resolver
• https://github.com/vivliostyle/vivliostyle.js/blob/master/packages/core/src/vivliostyle/cfi.ts
• https://github.com/johnfactotum/foliate-js/blob/main/epubcfi.js
• https://github.com/futurepress/epub.js/blob/master/src/epubcfi.js -- https://github.com/futurepress/EpubCFI/blob/master/src/epubcfi.js
• https://github.com/readium/readium-cfi-js
• https://github.com/satorumurmur/bibi/blob/master/__src/bibi/extensions/epubcfi.js
• Colibrio? ( https://api-docs.colibrio.com/web/3.9.0/modules/colibrio_core_selector_epubcfi.html )

Thank you! Daniel

[larscwallin]

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):

• https://github.com/fread-ink/epub-cfi-resolver

https://github.com/vivliostyle/vivliostyle.js/blob/master/packages/core/src/vivliostyle/cfi.ts

• https://github.com/johnfactotum/foliate-js/blob/main/epubcfi.js
• https://github.com/readium/readium-cfi-js

https://github.com/satorumurmur/bibi/blob/master/__src/bibi/extensions/epubcfi.js

• Colibrio? :)

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: @.***>