You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clarification about "OCF ZIP container that specifies the [zip] file is split across multiple storage media" #2360
My reading of this is neither of the two (but I agree it is unclear and may require a better explanation). I believe what the text refers to is the possibility for a zip file to be split into chunks that are sent over separately. I do not know what the authoritative reference for this type of feature is, my cursory look found [1][2].
If this is really what the founding fathers of EPUB referred to, it is unclear to me whether (a) this is an issue to be specified in the format specification instead of letting individual implementations handle it and (b) why referring to "multiple storage media" in the spec (if we decide to keep this in the spec, that is).
(There's no way to deep link into the app note for any of the zip requirements and mentioning section numbers always breaks in time.)
Without the restriction, reading systems would have to handle zip files split across different media, which I can't see making a lot of sense for EPUBs. I imagine no one wanted to deal with that scenario, so better to ban it than add a point of support inconsistency. It's been banned since at least OCF 2.0, though, so before my time.
ok, thanks for the clasification. Now it makes easier to create some test.
Yeah my guess is this is probably a heritage but could not find a working OCF 2 link anymore. Without thinking about history I kinda suspect if we really need to ban this. Zip format is also very useful for distributing to like Content Management System rather than reading system and sometimes I have seen really huge epub file (mostly including audio or video files) but I don't have a strong use case for splitting epub file yet. Let me also ask here w3c-cg/publishingcg#38. But I think good to close this one since I got answer.
Without the restriction, reading systems would have to handle zip files split across different media, which I can't see making a lot of sense for EPUBs. I imagine no one wanted to deal with that scenario, so better to ban it than add a point of support inconsistency. It's been banned since at least OCF 2.0, though, so before my time.
I still want to understand the exact range of the ban. Some scenarios:
I split the EPUB file and fetch the various pieces via distinct HTTP calls
I split the EPUB file and send each piece on separate USB sticks by snail mail
I split the EPUB file and send one piece via USB stick, and I fetch the other via an HTTP call
In my reading (1) is fine, (3) is forbidden, whereas (2) is probably forbidden because the USB sticks are different media "instances". But, conceptually, I am not sure any of these three scenarios are really different from one another, because the spec does not disallow the splitting of an EPUB file, only in case of "multiple storage media". Of is (1) also forbidden?
I guess what I do not really understand is what is meant by "multiple storage media". Or do we simply say that we disallow the splitting of the ZIP file in the first place?
I guess what I do not really understand is what is meant by "multiple storage media". Or do we simply say that we disallow the splitting of the ZIP file in the first place?
Has anyone ever encountered an EPUB in the wild that is split into multiple ZIPs?
My first instinct is to ban this practice altogether.
Ya, I'd expect RS developers would be more interested in streaming zip contents than in having chunks of a zip file to obtain.
Getting the chunks over http is also not defined, so unless the pieces are all in the same folder and use the z# naming convention then how does this even work?
I'd favour removing the "multiple media" part to make clear we ban all splitting.
To get chunks over http I used Range Request before in one of my epub project.
A side question tho: What kind of streaming epub contents would we (as WG) expect to see that happen in the future? Could be some good candidate for next gen of spec :)
Activity
iherman commentedon Jul 18, 2022
My reading of this is neither of the two (but I agree it is unclear and may require a better explanation). I believe what the text refers to is the possibility for a zip file to be split into chunks that are sent over separately. I do not know what the authoritative reference for this type of feature is, my cursory look found [1][2].
If this is really what the founding fathers of EPUB referred to, it is unclear to me whether (a) this is an issue to be specified in the format specification instead of letting individual implementations handle it and (b) why referring to "multiple storage media" in the spec (if we decide to keep this in the spec, that is).
cc @dauwhe @bduga @mattgarrish @TzviyaSiegman
mattgarrish commentedon Jul 18, 2022
It's defined in section 8 of the zip app note.
(There's no way to deep link into the app note for any of the zip requirements and mentioning section numbers always breaks in time.)
Without the restriction, reading systems would have to handle zip files split across different media, which I can't see making a lot of sense for EPUBs. I imagine no one wanted to deal with that scenario, so better to ban it than add a point of support inconsistency. It's been banned since at least OCF 2.0, though, so before my time.
Jeffxz commentedon Jul 18, 2022
ok, thanks for the clasification. Now it makes easier to create some test.
Yeah my guess is this is probably a heritage but could not find a working OCF 2 link anymore. Without thinking about history I kinda suspect if we really need to ban this. Zip format is also very useful for distributing to like Content Management System rather than reading system and sometimes I have seen really huge epub file (mostly including audio or video files) but I don't have a strong use case for splitting epub file yet. Let me also ask here w3c-cg/publishingcg#38. But I think good to close this one since I got answer.
iherman commentedon Jul 18, 2022
I still want to understand the exact range of the ban. Some scenarios:
In my reading (1) is fine, (3) is forbidden, whereas (2) is probably forbidden because the USB sticks are different media "instances". But, conceptually, I am not sure any of these three scenarios are really different from one another, because the spec does not disallow the splitting of an EPUB file, only in case of "multiple storage media". Of is (1) also forbidden?
I guess what I do not really understand is what is meant by "multiple storage media". Or do we simply say that we disallow the splitting of the ZIP file in the first place?
dauwhe commentedon Jul 18, 2022
Has anyone ever encountered an EPUB in the wild that is split into multiple ZIPs?
My first instinct is to ban this practice altogether.
mattgarrish commentedon Jul 18, 2022
Ya, I'd expect RS developers would be more interested in streaming zip contents than in having chunks of a zip file to obtain.
Getting the chunks over http is also not defined, so unless the pieces are all in the same folder and use the z# naming convention then how does this even work?
I'd favour removing the "multiple media" part to make clear we ban all splitting.
Jeffxz commentedon Jul 18, 2022
+1 to replacing "multiple media" with "splitting zip" to reduce ambiguous.
Jeffxz commentedon Jul 18, 2022
To get chunks over http I used Range Request before in one of my epub project.
A side question tho: What kind of streaming epub contents would we (as WG) expect to see that happen in the future? Could be some good candidate for next gen of spec :)