MobileRead Forums - View Single Post - toc.ncx error with playOrder causes validation failure

KevinH · 12-05-2014, 10:23 AM

Hi Peter,

If you can point me to any spec that says that your way is the right way to do things (outside of the Talking Book spec which uses SMIL time references) I would be happy to take a stab and trying to address this. But without a clear spec one way or the other, I really think you should just properly use "id" attributes to do what you want and still make it pass whatever check there is.

As for rules in epubcheck*, they are many many times very arbitrary. For example in early versions of epubcheck 3, they decided that in epub3 there can be a DOCTYPE on top of the toc.ncx (if present for fallback) - which according to the spec, the toc.ncx should have been totally ignored - so that made sense. But in more current versions they have decided to mark that as an "error" for some reason claiming that nothing can have a DOCTYPE that references external namespaces and dtds parsing information. Then someone nicely pointed out to them that some valid toc.ncx files are unparse-able without the proper DOCTYPE with dtds, so how could the toc.ncx be used as a fallback for epub2 without a DOCTYPE? So now in epubcheck4 pre-releases that "error" is no longer an "error".

The spec for epub3 also clearly states that the old form of the metadata in the opf is allowed to be there (and must be there to specify the cover page properly in most readers) but must be ignored, but then they actually report back errors on what was supposed to be "ignored". If it was valid metadata in epub2 format it should be properly ignored in epub3 if it doesn't fit, and they ignore that as well.

You'll find this same pattern again and again. Simply read the epubcheck bug database to see how often this happens and how arbitrary some of these rules really are. So claiming that the epubcheck validator claims it is a bug, can in fact be totally meaningless.

That is why I like to read the spec itself. So if you can find a spec online that clearly states how we do things is wrong, I would be happy to look at it. But if not, I think you should simply add the proper id attributes and be done with it.

KevinH

12-05-2014, 10:23 AM	#20
KevinH Sigil Developer Posts: 8,939 Karma: 6361444 Join Date: Nov 2009 Device: many	Hi Peter, If you can point me to any spec that says that your way is the right way to do things (outside of the Talking Book spec which uses SMIL time references) I would be happy to take a stab and trying to address this. But without a clear spec one way or the other, I really think you should just properly use "id" attributes to do what you want and still make it pass whatever check there is. As for rules in epubcheck, they are many many times very arbitrary. For example in early versions of epubcheck 3, they decided that in epub3 there can be a DOCTYPE on top of the toc.ncx (if present for fallback) - which according to the spec, the toc.ncx should have been totally ignored - so that made sense. But in more current versions they have decided to mark that as an "error" for some reason claiming that nothing can have a DOCTYPE that references external namespaces and dtds parsing information. Then someone nicely pointed out to them that some valid toc.ncx files are unparse-able without the proper DOCTYPE with dtds, so how could the toc.ncx be used as a fallback for epub2 without a DOCTYPE? So now in epubcheck4 pre-releases that "error" is no longer an "error". The spec for epub3 also clearly states that the old form of the metadata in the opf is allowed to be there (and must be there to specify the cover page properly in most readers) but must be ignored, but then they actually report back errors on what was supposed to be "ignored". If it was valid metadata in epub2 format it should be properly ignored in epub3 if it doesn't fit, and they ignore that as well. You'll find this same pattern again and again. Simply read the epubcheck bug database to see how often this happens and how arbitrary some of these rules really are. So claiming that the epubcheck validator claims it is a bug, can in fact be totally meaningless. That is why I like to read the spec itself. So if you can find a spec online that clearly states how we do things is wrong, I would be happy to look at it. But if not, I think you should simply add the proper id attributes and be done with it. KevinH Last edited by KevinH; 12-05-2014 at 10:47 AM.*