Metadata link element urls not being updated

[thiago.eec]

Hi, @Doitsu.

I have a doubt about an error msg suposedly thrown by EpubCheck. The error message is:

WARNING (RSC-007W): Referenced resource could not be found in the EPUB.

The error is pointing this entry on the <metadata> section of the opf file:

<link rel="onix-record" href="meta/9788584850396.xml" />

But the file is indeed on the referenced location (inside "meta" folder). Pagina EpubCheck does not show this error. Your Calibre version of this plugin also doesn't complain about this.

Only the Sigil plugin is throwing this error.

Is this a bug? Maybe because is on the META folder? But this is the standard procedure suggested by the ePub 3 specs.

[Doitsu]

Originally Posted by thiago.eec

But the file is indeed on the referenced location (inside "meta" folder). Pagina EpubCheck does not show this error. Your Calibre version of this plugin also doesn't complain about this.

Sigil changes the folder structure of epubs. If your original epub contained a meta folder, Sigil most likely moved all files from that folder to the Misc folder.
Open your epub with Sigil and check the Misc folder for files.
(If you didn't disable (Mend XHTML > Source Code On > Open), Sigil should update the path of all files moved to the Misc folder and epubcheck shouldn't report problems.)

[DiapDealer]

Sigil won't update the path and all references to an unmanifested file (and per epub3 spec: files referenced in metadata link elements must be unmanifested). Looks like this falls through the cracks of Sigil's EPUB3 support in general.

[thiago.eec]

Originally Posted by Doitsu

Sigil changes the folder structure of epubs. If your original epub contained a meta folder, Sigil most likely moved all files from that folder to the Misc folder.
Open your epub with Sigil and check the Misc folder for files.
(If you didn't disable (Mend XHTML > Source Code On > Open), Sigil should update the path of all files moved to the Misc folder and epubcheck shouldn't report problems.)

I unchecked this option (and to mend on save too), hoping it would prevent Sigil making this kind of automatic change. The bad news is: not only Sigil is rearrenging my folder structure, but it is DELETING my onix file. I saved it and checked. It is nowhere to be found... Thats really bad on Sigil. I'll try to open a Ticket on Github about this problem.

Originally Posted by DiapDealer

Sigil won't update the path and all references to an unmanifested file (and per epub3 spec: files referenced in metadata link elements must be unmanifested). Looks like this falls through the cracks of Sigil's EPUB3 support in general.

Yes... it's not manifested. But, as you said, it's just following the spec.


Thank you, guys!

[DiapDealer]

Originally Posted by thiago.eec

not only Sigil is rearrenging my folder structure, but it is DELETING my onix file. I saved it and checked. It is nowhere to be found... Thats really bad on Sigil.

To be fair: it's the first instance of the epub spec insisting on an unmanifested file that I can recall.

[thiago.eec]

Originally Posted by DiapDealer

To be fair: it's the first instance of the epub spec insisting on an unmanifested file that I can recall.

I guess that's true. Also, Sigil is a great free software. I can't complain.
I just wish there was a way Sigil wouldn't rearrange my folder structure. The user should have the option to choose.

[KevinH]

We will have to special case that opf link tag as my understanding was that it can only be used to point to EXTERNAL metadata resources and was never designed to create an unmanifested file inside the epub.

FWIW, I have never seen a commercial epub3 that used it in that way. Instead the extra logistics/manufacturing metadata was hosted externally.

I will double check the official spec to confirm one way or the other.

Update: Yes the href attribute does allow a relative iri in the opf metadata link tag so we will have to special case this when opening the epub. I just never saw it used that way and therefore Sigil does not handle it now, but it soon will.

[Doitsu]

Originally Posted by KevinH

FWIW, I have never seen a commercial epub3 that used it in that way. Instead the extra logistics/manufacturing metadata was hosted externally.

So far I haven't seen embedded Onix files in epub3 books either. AFAIK, Onix references are mostly used to indicate 13 digit ISBN numbers. For example:

<dc:source id="src-id">urn:isbn:9780141194523</dc:source>
<meta property="identifier-type" refines="#src-id" scheme="onix:codelist5">15</meta>
<dc:identifier id="book_id">urn:isbn:9780141963624</dc:identifier>
<meta property="identifier-type" refines="#book_id" scheme="onix:codelist5">15</meta>

(ONIX code list 5 contains product identifier types. 15 = ISBN-13.)

[DiapDealer]

Thanks for checking into it, Kevin.

[thiago.eec]

Originally Posted by KevinH

FWIW, I have never seen a commercial epub3 that used it in that way. Instead the extra logistics/manufacturing metadata was hosted externally.

Actually, the ONIX record is not just about logistics/manufacturing. Its a full metadata record, that carries a lot more info about the book then its possible to register on the metadata section of the opf file.

But, to be honest: I'm just an enthusiast and not a publishing professional, so I don't really know how Publishers and Reading Systems really use those records.

Originally Posted by KevinH

Update: Yes the href attribute does allow a relative iri in the opf metadata link tag so we will have to special case this when opening the epub. I just never saw it used that way and therefore Sigil does not handle it now, but it soon will.

Thank you very much for the quick response and possible correction!

Originally Posted by Doitsu

So far I haven't seen embedded Onix files in epub3 books either. AFAIK, Onix references are mostly used to indicate 13 digit ISBN numbers. For example:

<dc:source id="src-id">urn:isbn:9780141194523</dc:source>
<meta property="identifier-type" refines="#src-id" scheme="onix:codelist5">15</meta>
<dc:identifier id="book_id">urn:isbn:9780141963624</dc:identifier>
<meta property="identifier-type" refines="#book_id" scheme="onix:codelist5">15</meta>

(ONIX code list 5 contains product identifier types. 15 = ISBN-13.)

The main reason why I gave ONIX a try was the direction the specs seemed to be taking. Epub 3.1 revision deprecated REFINES atribute, keeping a more restrict set of metadata available directly on the opf file. The specs encouraged authors to use linked records for provindig more complete metadata info. Also, now, LINKED RECORDS take precedence over PACKAGE METADATA. So, I thought it would be wise to provide a full record via an onix file.

Epub 3.2 is intended to update 3.1 in order to maintain backward compatibility with 3.0.1, wich was broke with 3.1. Now, REFINES is back, but it will retain the precedence definition of 3.1 (linked metadata > package metadata). So, for now, using REFINES allows me to provide great metadata on the PACKAGE. But, the specs are clearly encouraging authors to use linked records to improve metadata info, leaving just the basics on the opf.

[DiapDealer]

I do know that the epub specs allow reading systems to ignore any and all metadata links (even ones internal to the epub). With that kind of "permission," it's not likely that any commercial epub rendering engines will be very quick to utilize them.

Just mentioning it; not making a judgement.

Also keep in mind that Sigil's EPUB3 support has not been extended to 3.01 or 3.1 (let alone 3.2). The spec is too volatile to even attempt to keep up.

[thiago.eec]

Originally Posted by DiapDealer

I do know that the epub specs allow reading systems to ignore any and all metadata links (even ones internal to the epub). With that kind of "permission," it's not likely that any commercial epub rendering engines will be very quick to utilize them.

Sure. Every time the specs permit something not to be implemented, Reading Systems will not have the trouble. See the epub:type feature... Its only implementation is for pop-up footnotes.

Originally Posted by DiapDealer

Just mentioning it; not making a judgement.

I just like to follow the specs, in the hope of future implementation and adoption. Is just like acessibility features: I'll do my best to use correct markup and follow both epub and aria guidelines; but I know much of it is still not used by the mainstream Reading Systems and even screen readers. Well, if they do not implement the specs, there's nothing I can do about it, but I'll keep doing my part.

Originally Posted by DiapDealer

Also keep in mind that Sigil's EPUB3 support has not been extended to 3.01 or 3.1 (let alone 3.2). The spec is too volatile to even attempt to keep up.

I know. Also, the recomendation now its not to use or implement 3.1, but jump directly to 3.2 (when finished). So, like you said: very volatile.

[DiapDealer]

@Doitsu: just say the word if you want me to break this conversation out of your plugin thread and into its own.

[KevinH]

@thiago.eec

I am working on adding support for unmanifested but local metadata link record files in epub3's.

So if you have a simple example epub that uses this feature that can be publicly shared, would you please post it as an attachment to this thread so that I can test with it.

If you only have private ones but are still willing to share it privately, would you please you pm KevinH with a link and I will delete it when I am done testing with it.

Thanks,

KevinH

[KevinH]

Okay, I have a potential "fix" for this but I will wait to test it with your test case (if possible) before pushing it to master.

Thanks for your bug report!