|
I think I get what people are saying here. Let me rephrase it.
What SLIS asked was, if they don't want to read EPUB3 books fully, but instead focus on a subset, why not just write a reader that reads EPUB3 books but only supports the subset.
The problem with that logic is, according to the EPUB3 specifications, you must do all or nothing. You can't make a reader that says it reads EPUB3 format that only supports part of the EPUB3 format. If you make an EPUB3 reader, it has to be able to (within reasonable limitations such as DRM) , read all EPUB3 documents. It even has to have the ability to plug-in DRM from multiple sources to enable new content owners to read it.
Apple has chosen to implement only a subset of EPUB3's requirements for their interactive books app. As such, they CANNOT call it EPUB. The reason they can't is because the reader cannot be an EPUB3 Reader. It works both ways, see? The epub version is encoded in the file. Apple cannot use their reader to differentiate between supported or unsupported Epubs. That breaks the standard, and so, they can't call their reader an EPUB reader.
So they elected to call it an .ibook reader. They moved around the issue. Yes, they did it in a proprietary way, but this was the end result ANYWAY. People would be equally complaining if they broke the standard and implemented their own "Epub 2.5"
What HarryT is saying is simply this:
What is the difference between implementing only a subset of features of EPUB3 and calling it .epub, and what Apple did, which was IMPLEMENT ONLY A SUBSET OF FEATURES OF EPUB3, and calling it .ibook?
|