Bug in epub metadata writer? Invalid attribute role="aut"

Man Eating Duck · 09-26-2012, 07:37 AM

After saving to disk, or using kiwidude's Modify epub plugin with update metadata, I get the error 'The "role" attribute is not an allowed attribute of the <creator> element.' when validating (FC and epubcheck). This is the offending line in content.opf:

Code:

    <dc:creator xmlns:ns1="http://www.idpf.org/2007/opf" ns1:file-as="Last, First" role="aut">Last, First</dc:creator>

Prior to updating metadata the file had an empty creator tag. Changing the offending attribute to ns1:role="aut" (specifying namespace?) fixes the problem.

In a fresh install of calibre portable I observe the same error when saving to disk. Am I doing something strange, or did I stumble upon a calibre bug?

The attached file will reproduce the problem (for me) if added to an empty library and then saved to disk.

kovidgoyal · 09-26-2012, 08:32 AM

That's a bug in XML. XML has no clear rules for how to interpret attributes with no namespace prefix. The spec says that default namespaces apply only to element names and not attribute names and that attribute names should be interpreted in the element namespace. But it also says that attribute with no prefix should be in the null namespace. So different XML tools deal with unprefixed attribute names differently. The XML library calibre uses treats unprefixed attributes to be in the default namespace, which means that there is no need to use opf:role, since opf is the default namespace already. Whatever XML library FC and epubcheck use makes a different assumption about how to interpret unprefixed namespaces, leading to the validation error. In practice, this validation error is meaningless, since tools that actually consume OPF either completely ignore the role attribute or handle both opf:role and role.

kovidgoyal · 09-26-2012, 08:59 AM

I added a workaround that tricks lxml into producing a prefixed role attribute, so that I dont have to deal with bug reports about this in the future.

Man Eating Duck · 09-26-2012, 09:55 AM

Sorry, it was not my intention to nag you... my workaround was no effort in any case.

I updated my source tree, and it works as expected now. Thanks a lot!

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Bug in Kobo processing of epub files causing hang in "Processing content"	BensonBear	Kobo Reader	21	12-21-2012 05:47 AM
Changing internal ePub title with "Edit metadata"	therealjoeblow	Conversion	3	11-03-2011 12:01 AM
Value of Attribute "Class" is Invalid Error	TFaire	ePub	2	09-23-2011 11:25 AM
Bug? "Insert metadata as page at start of book" doesnt encode Comments field properly	rollercoaster	Calibre	2	04-24-2010 10:40 PM
Error message : "Invalid Format" " Do you want to format your internal memory"	narbeauchamp	Sony Reader	11	07-22-2009 12:39 PM

09-26-2012, 08:32 AM	#2
kovidgoyal creator of calibre Posts: 44,289 Karma: 23661992 Join Date: Oct 2006 Location: Mumbai, India Device: Various	That's a bug in XML. XML has no clear rules for how to interpret attributes with no namespace prefix. The spec says that default namespaces apply only to element names and not attribute names and that attribute names should be interpreted in the element namespace. But it also says that attribute with no prefix should be in the null namespace. So different XML tools deal with unprefixed attribute names differently. The XML library calibre uses treats unprefixed attributes to be in the default namespace, which means that there is no need to use opf:role, since opf is the default namespace already. Whatever XML library FC and epubcheck use makes a different assumption about how to interpret unprefixed namespaces, leading to the validation error. In practice, this validation error is meaningless, since tools that actually consume OPF either completely ignore the role attribute or handle both opf:role and role.

09-26-2012, 08:59 AM	#3
kovidgoyal creator of calibre Posts: 44,289 Karma: 23661992 Join Date: Oct 2006 Location: Mumbai, India Device: Various	I added a workaround that tricks lxml into producing a prefixed role attribute, so that I dont have to deal with bug reports about this in the future.

09-26-2012, 09:55 AM	#4
Man Eating Duck Addict Posts: 254 Karma: 69786 Join Date: May 2006 Location: Oslo, Norway Device: Kobo Aura, Sony PRS-650	Sorry, it was not my intention to nag you... my workaround was no effort in any case. I updated my source tree, and it works as expected now. Thanks a lot!

Advert