Quote:
Originally Posted by theducks
One has to wonder 
Why this would need to be done?
When the purpose of the tool is to generate a valid OPF |
I know some people create epub templates and want to avoid having all books have the same UUID as the BookID, but in that case, the best way forward is to create an additional
new UUID entry and point the book ID from the package element at the new one. But I'm not sure that would even work (the one in the NCX needs to updated to match). Diddling with the existing UUID/BookID of an epub currently open in Sigil is just pretty-much a surefire way to wind up with a broken/reordered opf.
Or some people want to add the ISBN, and mistakenly think it has to be THE BookID. You can add the ISBN and leave the existing UUID in place. There is no inherent value/benefit in having the ISBN
BE the unique BookID.
The fact of the matter is ... you can add a scad of UUIDs and other relevant identifiers to the OPF, but unless you're creating an epub template (and want to avoid duplicate BookIDs), there's no good reason not to just leave the existing UUID/BookID pair alone. I have no idea why a namespace in the opf would need to be changed (with Sigil).
I'll look into making a plugin (I had one in the old "Open With" plugin hack we had going a long time ago) to generate a new UUID. The template thing is a good enough reason to need something like that (even though I don't know of any reading system that actually depends--or even checks on--the uniqueness of the BookID).