opf:meta... change not accepted by Sigil

[jtweeks]

An epub upload to Google Play e-reader is failing.

I interpret the epubcheck error message (below) to require changing "meta..." entries to "opf:meta..." in the OEBPS/content.opf file.

When I try to change the "meta..." entries in the OEBPS/content.opf folder to "opf:meta..." and then run the "Well-formed Check - F7" the "opf:meta" changes revert back to "meta...".

Am I misinterpreting this error message? Perhaps there are other required changes to this file?

The epubcheck error message:

ERROR(RSC-005): ESV_Study_Bible.epub/OEBPS/content.opf(16,57): Error while parsing file: element "meta" not allowed anywhere; expected the element end-tag or element "dc:contributor", "dc:coverage", "dc:creator", "dc:date", "dc:description", "dc:format", "dc:identifier", "dc:language", "dc:publisher", "dc:relation", "dc:rights", "dc:source", "dc:subject", "dc:title", "dc:type", "opf:link" or "opf:meta"

The OEBPS/content.opf contains:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
<dc:title>ESV® Study Bible</dc:title>
<dc:creator>Crossway</dc:creator>
<meta property="role" refines="creator" scheme="marc:relators">pbl</meta>
<dc:language>en-us</dc:language>
<dc:identifier id="BookId">9781433518874-2013-11</dc:identifier>
<dc:identifier id="ISBN">urn:isbn:9781433518874</dc:identifier>
<dc:publisher>Crossway</dc:publisher>
<dc:subject>Spiritual Religion</dc:subject>
<dc:description>The ... resources.</dc:description>
<meta name="Sigil version" content="2.6.0"/>
<meta property="dcterms:modified">2026-07-10T13:23:35Z</meta>

[DiapDealer]

What's your package tag look like near the top of the content.opf file?

[KevinH]

Could it be the older self-closing meta tag with name and contents?

[KevinH]

Oh I see, ... they are declaring the opf prefix on the metadata tag itself. Normally the meta tags do not need an opf prefix when it is defined in the package tag as the default namespace (no prefix required).

Just removing that opf prefix namespace from the metadata tag itself should do the trick.

Sigil's default package tag should look like:

<package version="3.0" unique-identifier="BookId" xmlns="http://www.idpf.org/2007/opf">

Notice the opf namespace is the default namespace which does not use the opf: prefix.

[jtweeks]

DiapDealer - I believe this is what you requested:
<package version="3.0" unique-identifier="BookId" prefix="ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/" xml:lang="en" xmlns="http://www.idpf.org/2007/opf">

[DiapDealer]

Originally Posted by KevinH

Just removing that opf prefix namespace from the metadata tag itself should do the trick.

But our default epub3 opf file includes the opf prefix namespace in the metadata tag (as well as the namespace in the package tag).

I can't get this error to happen even if I directly copy the metadata from the first post into an epub 3. I'm beginning to think there might be an invisible character messing things up somewhere.

The meta refine is incorrect in the OP, but that still doesn't trigger the error they're getting.

[KevinH]

The package tag declares the tags in this file are in the opf namespace with no prefix needed.

In his metadata tag he has added that same namespace as needing an opf prefix. Just removing that opf namespace from the metadata tag should be enough for any decent xml parser.

And yes you are right there could another cause but my guess is that validators xml processor is just confused by it.

Our epub3 default opf lookslike this:

static const QString TEMPLATE3_TEXT =
    "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
    "<package version=\"3.0\" unique-identifier=\"BookId\" xmlns=\"http://www.idpf.org/2007/opf\">\n\n"
    "  <metadata xmlns:dc=\"http://purl.org/dc/elements/1.1/\">\n"
    "    <dc:identifier id=\"BookId\">urn:uuid:%1</dc:identifier>\n"
    "    <dc:language>%2</dc:language>\n"
    "    <dc:title>%3</dc:title>\n"
    "    <meta property=\"dcterms:modified\">%4</meta>\n"
    "  </metadata>\n\n"
    "  <manifest>\n"
    "  </manifest>\n\n"
    "  <spine>\n"
    "  </spine>\n\n"
    "</package>";

Notice the metadata tag only adds the dc namespace with the dc: prefix. The opf: prefix is not needed as it is the default.

[DiapDealer]

His metadata tag is the same as what I see when I open a new, empty epub3 in Sigil. The top of my opf looks like this:

<?xml version="1.0" encoding="utf-8"?>
<package version="3.0" unique-identifier="BookId" xmlns="http://www.idpf.org/2007/opf">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">

That is what I get on Windows and Linux when I open a brand new empty epub3. ???

For what it's worth, the EpubCheck plugin in Sigil doesn't seem to care whether the xmlns:opf="http://www.idpf.org/2007/opf"is in the metadata tag or not. But I am curious what might be putting it there if it's not part of Sigil's default opf for an epub3.

[KevinH]

Huh? That is strange. The entire opf is in the opf xml namespace so no prefix is needed or used. No idea where it gets added to the metadata tag. It must be someplace.
I will try to track down where that is added and why.

[KevinH]

Here is where it gets unconditionally added:

https://github.com/Sigil-Ebook/Sigil...arser.cpp#L442

For epub3, this should not be needed. But every time the opf is modified it is parsed and that damn ns is added to the metadata tag. It should not make any differece to things (it just means opf: prefixed versions and non-prefixed versions should be recognized inside metadata but that is what I fear is upsetting the validator in this case.

But that is just a guess. We should probably make that line be conditioned on the package version, epub2 vs epub3. Or better yet change it completely to always add the dc namespace.

I am just unsure why this is causing any errors at all. And epubcheck is okay with it. Sigil's opf parser will always serialize to its simplest form (not using prefixed namespaces unless required).

So strange.

[DiapDealer]

I don't think any of this is causing the epubcheck error the OP is seeing. I've recreated their package and metadata section of the opf (using the data they provided) using Sigil's default epub3, and the only opf error that epubcheck reports is about the meta refine not pointing to a valid entry.

I'm also not entirely sure what is meant by "An epub upload to Google Play e-reader is failing."

[DiapDealer]

I'm back to your initial suggestion:

Originally Posted by KevinH

Could it be the older self-closing meta tag with name and contents?

Current Sigil and epubcheck don't flag the Sigil version entry as an error, but wasn't there an older version of epubcheck that did?

I can't imagine why it would prevent an epub from being readable by Google Play Books, but maybe they should just try removing that entry and see if it allows the book to be read. That's about all I have. *shrug*

[KevinH]

But the older epub2 style meta tag is technically to be completely ignored under the epub3 spec. It is not an error, at least not according to the spec at all.

[DiapDealer]

Originally Posted by KevinH

But the older epub2 style meta tag is technically to be completely ignored under the epub3 spec. It is not an error, at least not according to the spec at all.

I agree. But I thought we'd had several "that's not supposed to be an error" things in EpubCheck that got corrected in later versions. I'm wondering if the version of epubcheck being used by the OP might be older and buggier. And it certainly wouldn't be the first time an epub3 rendering engine barfed on something it wasn't supposed to barf on.

But without being able to recreate the error with the data given, I'm just grasping at straws here.

[KevinH]

Hmm ... could be. Google Play will try to validate an epub3 you upload to it and parse errors will cause it to stop uploading.

What we really need is the real full output of epubcheck on that epub just in case there are other parse errors.

As Sigil simplifying the OPF is completely correct xml that epubcheck has never had an issue with.