Potentially update longdesc to be its own file

[robinwhittleton]

I was looking at a five-year-old proposal from Alex to allow HTML in descriptions (w3c/epub-specs#1650), and I note that this was resolved in EPUB 3.3 in favour of allowing external HTML files to act as descriptions: https://www.w3.org/TR/epub-33/#example-link-to-a-description

I guess we don’t want to do anything here (at least at this point) as the compatibility changes would potentially be quite painful, but here’s a proposed process if we decide we should.

1. Drop the existing dc:description from content.opf.
2. Create a new /src/epub/description.html file for the long description to live in. (xhtml?)
3. Change the meta property="se:long-description" element to be <link rel="dcterms:description" href="description.html" media-type="text/html"/>. (application/xhtml+xml?)
4. Add a new inline_description function to se_epub_build.py` that strips the markup from description.html’s main section and inlines the resulting text.
5. Update the website to expect to extract the longdesc from description.html.
6. Update the step-by-step guide, SEMoS, etc etc.

Updating the corpus should be fairly easily scriptable.

[acabal]

Hmm, even though I was in that discussion I don't remember seeing any of that new feature happening. Maybe I just forgot?

In any case, doesn't this solution remove the dc:description short description, which is different than the long description? We want both.

Are dc:description and dcterms:description the same thing? I don't think they differentiate between 'short' and 'long', which we do.

[robinwhittleton]

The alternative solution was discussed in w3c/epub-specs#1666.

It removes the short description, yes. But I can’t anything that says that a dc:description needs to be short. Dublin Core just says it can be a “free-text account of the resource”. We don’t actually use the shortdesc right? It’s specifically for readers / librarying software? In which case I think I’d rather personally have the full blurb, that’s currently not available there.

[acabal]

We do use the short description, for example in our monthly summary newsletters. Currently dc:description is basically a logline and se:long-description is a back-of-the-book blurb, which serve different purposes and are each useful.

Strictly speaking I suppose the way we use dc:description should really be dc:abstract. Then we could update dc:description to be the full HTML using this method. But since historically dc:description did not support HTML, and there was no way to formally inform ereaders that the contents of dc:description are HTML and not plain text, we had to do it the way we did, which is to include HTML in a custom <meta>.

Of course, the broader question is, what is ereader support for linking like this? I'm guessing nonexistent. We would risk showing no descriptions in ereaders that currently do understand dc:description.

And, the way we currently do it now is still valid epub anyway, we're just doing it in a custom namespace.

(BTW, on this same page I also see an example for linking to homepages, we could also adapt that: https://www.w3.org/TR/epub-33/#example-declaring-a-new-link-relationship )

[robinwhittleton]

I would assume no support as well. But that hasn’t necessarily stopped us before if we can code a sane fallback. Having said that, no problem if we want to not do this until there was more support.

This was triggered by me missing having the longer description available in the details view on Kobo. A slightly fuzzy photo of a non-SE book on my reader shows that it’s possible to have longer descriptions show up in the synopsis there at least, though that conceivably could be Kobo Store functionality.

[acabal]

You'd have to extract that epub to see how they do it.

I'm interested in the idea, but keeping both short and long descriptions using dc:abstract, and keeping compatibility in the compatible epub. Also the website would need significant updates to understand any new metadata layouts. So if you want to put together a complete proposal then go for it. You should also test your proposals on any ereaders you can get your hands on - iBooks if you have an iPad, or download some of the major apps on whatever phone/tablet you have.

[acabal]

Thinking more on this, a good starting point will be to do a survey of some of the common ereaders and devices to see how each one treats dc:description, whether they support/understand dc:abstract, and whether either of those properties can render HTML; and whether they support <link rel="dcterms:description"> .

Once we get a matrix down we can better understand how to approach this while preserving compatibility. I think the big problem will be that it's unlikely that most readers accept HTML in dc:description, which is another reason why using a custom <meta> for the long description is safe.