Tests for manifest item fallback, unclear expected outcome

[danielweck]

Tests for manifest item fallback, unclear expected outcome

[danielweck]

The expectation is clear with the test that has a specific XML content type:

epub-tests/tests/pub-foreign_xml-suffix-spine/EPUB/package.opf

Lines 20 to 27 in 9a023ce

	<manifest>
	<item id="content_primary" fallback="content_fallback" href="moby.xml" media-type="application/dtc+xml" />
	<item id="content_fallback" href="content_001.xhtml" media-type="application/xhtml+xml" />
	<item id="nav" properties="nav" href="nav.xhtml" media-type="application/xhtml+xml" />
	</manifest>
	<spine>
	<itemref idref="content_primary" />
	</spine>

... but conversely the "plain" application/xml test is problematic because XHTML itself is XML, so the description of the expected outcome needs to be clarified:

epub-tests/tests/pub-foreign_xml-spine/EPUB/package.opf

Lines 20 to 27 in 9a023ce

	<manifest>
	<item id="content_primary" fallback="content_fallback" href="moby.xml" media-type="application/xml" />
	<item id="content_fallback" href="content_001.xhtml" media-type="application/xhtml+xml" />
	<item id="nav" properties="nav" href="nav.xhtml" media-type="application/xhtml+xml" />
	</manifest>
	<spine>
	<itemref idref="content_primary" />
	</spine>

More specifically:

If the reading system does not support XML, it should display the HTML.

epub-tests/tests/pub-foreign_xml-spine/EPUB/package.opf

Lines 8 to 11 in 9a023ce

	<dc:description>
	This EPUB uses an ordinary XML content file with mimetype application/xml in the spine, with a manifest fallback to an
	HTML document. If the reading system does not support XML, it should display the HTML.
	</dc:description>

[danielweck]

Similarly with the JSON test, I struggle to understand the criteria for fail vs. pass:

epub-tests/tests/pub-foreign_json-spine/EPUB/package.opf

Lines 20 to 27 in 9a023ce

	<manifest>
	<item id="content_primary" fallback="content_fallback" href="moby.json" media-type="application/json" />
	<item id="content_fallback" href="content_001.xhtml" media-type="application/xhtml+xml" />
	<item id="nav" properties="nav" href="nav.xhtml" media-type="application/xhtml+xml" />
	</manifest>
	<spine>
	<itemref idref="content_primary" />
	</spine>

Let's say my reading system claims to support application/json by displaying its raw contents in the publication viewport, thereby ignoring the fallback XHTML. Is that a pass? In the absence of clear content processing model for JSON, it's hard to assert success.

(Naturally, in the real world I would expect most reading systems to follow the fallback chain to XHTML, but that's beside the point)

[gautierchomel]

see related discussion #245

Regarding pub-foreign_bad-fallback what happens is that Thorium open system dialog and ask where to save the file. I find it's a useful feature :)

I consider it "n/a" (no fallback is needed as access to the file is provided).

Same for pub-foreign_json-spine and pub-foreign_xml-spine