OPDS Namespace Update

[halkeye]

Changed

• Changed: Updated OPDS Namespaces to match the spec more closely

[majora2007]

Moving dev's comment here:

---

I looked at calibre-web and Project Gutenberg's opds files, as well as some other random atom xml feeds, its common to use dc: and opensearch: and pse:

This can help those doing regex based xml parsing (like koreader, even though its not using those fields atm) rather than true xml parsing

Example:
Old:

<totalResults xmlns="http://a9.com/-/spec/opensearch/1.1/">283</totalResults>

New

<opensearch:totalResults>283</totalResults>

[zeedif]

I don't believe Calibre is a reliable reference; it takes liberties with the EPUB specification, so it likely does the same with OPDS. The same logic applies to Project Gutenberg; just because a project implements something a certain way doesn't make it correct, and we shouldn't perpetuate non-standard practices. Our single source of truth should be the official specification (https://specs.opds.io/opds-1.2).

Regarding halkeye's changes, the move to explicit XML namespace prefixes (dc:, opensearch:) is correct and aligns with the examples in the specification.

However, opensearch:totalResults should not be used across all acquisition feeds. Section 3 of the OPDS 1.2 specification explicitly states these elements may be included "in [OpenSearch] responses," reserving them for search results. For general feed pagination, OPDS defers to a native Atom mechanism defined in RFC 5005 (Feed Paging and Archiving). This standard relies on <link> elements with rel attributes like next, previous, first, and last to navigate paged content. This is the spec-compliant way to handle pagination and doesn't require out-of-context elements from another namespace.

The approach should be to provide first-class support for the specification first. Compatibility behaviors should then be treated as extensions, not as the default implementation.