Using the ISBN as "BookID" instead of UUID

[ibu]

An ISBN number is a unique ID.

When I declare one in the metadata editor I wish to use it as "BookID".

Is it possible to configure Sigil in that way?

By default Sigil always adds an UUID.

Thanks.

Edit:
I added this idea as a feature wish in the issue database of Sigil.
If anyone likes to vote, comment ...

[DiapDealer]

Is it possible to configure Sigil in that way?

Configure Sigil to automatically do it that way? No. New ePubs will always have a unique ID automatically generated. A unique identifier is required by the ePub specs, afterall (required to BE there, there is no mechanism to enforce of the actual uniqueness of said identifier in ePub). And since Sigil won't yet know what the ISBN of your brand new ePub might be, it will generate a UUID to ensure compliance in the meantime.

It's quite trivial to change your ePub to use the ISBN identifier as the unique identifier (in Sigil) and get rid of the autogenerated UUID at any time, however:

Add the ISBN metadata (either through the metadata editor or add it manually in the OPF). Open the OPF file and add an id attribute to the isbn dc:indentifier entry you just created (I often use "isbn" but just so long as it's not the same as the "unique-identifier" attribute of the "package" element). Then change the "unique-identifier" attribute of the "package" element to match the id you just created for your ISBN entry. Save the epub and delete the entire <dc:identifier></dc:identifier> entry for the old UUID from the OPF.

[ibu]

Originally Posted by DiapDealer

Configure Sigil to automatically do it that way?

Yes, that's my wish.

Originally Posted by DiapDealer

No. New ePubs will always have a unique ID automatically generated. A unique identifier is required by the ePub specs, afterall (required to BE there, there is no mechanism to enforce of the actual uniqueness of said identifier in ePub). And since Sigil won't yet know what the ISBN of your brand new ePub might be, it will generate a UUID to ensure compliance in the meantime.

I think of an option like:
[x] Delete UUID automatically, if an ISDN exist and use it as BookID


Of course I know how to delete it manually in the code.

My wish is, that Sigil supports the editor in producing OPFs which are as free as possible from superfluous code.

If developers are reading this thread: please just take my wish as a suggestion

Another option I'm looking for:

Change the pattern of the automatically generated IDs:

Now:
id="title.xhtml"
id="ch01.xhtml"

I prefer:
id="title"
id="ch01"

In other words: Just the filename as ID, without the extension.

[Toxaris]

If you are already calling this superfluous code... It will save only a few bytes and will not make your file easier to read.

With regards to the us's, more extensions are possible. If the extension is omitted, it would not always be clear what file is meant.

[ibu]

Originally Posted by Toxaris

If you are already calling this superfluous code... It will save only a few bytes and will not make your file easier to read.

Of course it's a question of taste.
My eyes prefer it, when IDs do not contain a part which is the same in almost every id.

Originally Posted by Toxaris

With regards to the us's, more extensions are possible. If the extension is omitted, it would not always be clear what file is meant.

Thanks for that objection.

I change my suggestion:
Just in the IDs of text-files the extension should be omitted.

[ibu]

Another question about code details inside the OPF:

Sigil generates the part with the metadata like this:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
   
    <dc:title xmlns:dc="http://purl.org/dc/elements/1.1/">Lorem Ipsum</dc:title>
[...]
</metadata>

Is it really necessary, that in each child element of the element metadata the

xmlns:dc="http://purl.org/dc/elements/1.1/"

has to be inserted?

The validator epubcheck says: no.

[Toxaris]

Originally Posted by ibu

I change my suggestion:
Just in the IDs of text-files the extension should be omitted.

Even for just the text files multiple extensions are possible. From the top of my head: xhtml, html and htm. I would not be suprised if the xml extension is also valid.

Whether it is good form to have various extension is another discusion.

[ibu]

@Toxaris
It is a rare special case with which you argue.

Special cases can be treated specially by a software.
Special cases should not lead into redundant code for standard cases.
IMHO.

/Text/foo.xhtml -> id="foo"
/Text/foo.html -> id="foo.html"
/Text/foo.htm -> id="foo.htm"
/Images/foo.jpg -> id="foo.jpg"

[Toxaris]

It is not a rare as you think. It is much, much easier just to add the extension, since that will work in all cases, especially when there is no real added value.

[ibu]

Originally Posted by Toxaris

It is not a rare as you think.

Please can you tell me a case, where an editor has good reasons to use a mix of htm, html and xhtml for text files.

Originally Posted by Toxaris

It is much, much easier just to add the extension, since that will work in all cases, especially when there is no real added value.

We disagree about the value in this particular case.
Consiseness has a high value in my view.
And of course it's higher effort for the developers to get a more consise output than a less consise.

[DiapDealer]

Originally Posted by ibu

Please can you tell me a case, where an editor has good reasons to use a mix of htm, html and xhtml for text files.

Good reasons for doing something have almost zero relevance when talking about a program that must automatically work for whatever someone might try to do with it ... without blowing up in a spectacular mess.

Anything that must try to automatically (and successfully) manipulate any and all code that might be thrown at it is always going to come at the expense of the loss of some control over the conciseness, the efficiency and the conventions of the code it produces.

[ibu]

Originally Posted by DiapDealer

Good reasons for doing something have almost zero relevance when talking about a program that must automatically work for whatever someone might try to do with it ... without blowing up in a spectacular mess.

Toxaris wrote, that it is not a rare case and I was curious. That's all.
To avoid a "spectacular mess" I already made a suggestion for the generation of IDs.
There's just a default file type: xhtml.
It get's the consise ids. Ready.

As I said before:
In my humble view consise and readable code - for standard cases - is valuable goal.

Irrational editors, which like messing around with their files, get a less consise code. Ready.

I created an example of a formatted OPF.
May be than it's easier to understand, what I'm talking about.

<?xml 
	version   ="1.0"
	encoding  ="UTF-8"
	standalone="yes"?>
<package 
	version          ="2.0"
	unique-identifier="book-id"
	xmlns            ="http://www.idpf.org/2007/opf"
	xmlns:dc         ="http://purl.org/dc/elements/1.1/"
	xmlns:opf        ="http://www.idpf.org/2007/opf">
	<metadata>
		<dc:language                                 >de-DE              </dc:language>
		<dc:title                                    >Lorem Ipsum        </dc:title>
		<dc:creator                 opf:role="aut"   >Erika Mustermann   </dc:creator>
		<dc:identifier id="book-id" opf:scheme="ISBN">978-3-86680-192-9  </dc:identifier>
		<dc:publisher                                >Adipisit Buchverlag</dc:publisher>
	</metadata>
	<manifest><!-- Alle Dateien -->
		<item id="toc"      href="toc.ncx"     media-type="application/x-dtbncx+xml" />
		<item id="coverimg" href="cover.jpg"   media-type="image/jpeg" />
		<item id="cover"    href="cover"       media-type="application/xhtml+xml" />
		<item id="title"    href="title"       media-type="application/xhtml+xml" />
		<item id="c01"      href="c01"         media-type="application/xhtml+xml" />
		<item id="c02"      href="c02"         media-type="application/xhtml+xml" />
	</manifest>
	<spine toc="toc"><!-- Reihenfolge von Textdokumenten -->
		<itemref idref="cover" />
		<itemref idref="title" />
		<itemref idref="c01" />
		<itemref idref="c02" />
	</spine>
	<guide><!-- Semantik von Textdokumenten -->
		<reference type="cover"      title="Buchdeckel" href="cover" />
		<reference type="title-page" title="Titelseite" href="title" />
	</guide>
</package>

To compare see a file, freshly generated with Sigil:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<package xmlns="http://www.idpf.org/2007/opf" unique-identifier="BookId" version="2.0">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
    <dc:identifier id="BookId" opf:scheme="UUID">urn:uuid:45273454-57d8-4eaf-944b-07671c27d565</dc:identifier>
    <dc:title>Lorem Ipsum</dc:title>
    <dc:creator opf:role="aut">Erika Mustermann</dc:creator>
    <dc:language>de-DE</dc:language>
    <dc:identifier opf:scheme="ISBN">978-3-86680-192-9</dc:identifier>
    <dc:publisher>Adipisit Buchverlag</dc:publisher>
    <meta content="cover.jpg" name="cover" />
  </metadata>
  <manifest>
    <item href="toc.ncx" id="ncx" media-type="application/x-dtbncx+xml" />
    <item href="Text/Section0001.xhtml" id="Section0001.xhtml" media-type="application/xhtml+xml" />
    <item href="Text/Section0002.xhtml" id="Section0002.xhtml" media-type="application/xhtml+xml" />
    <item href="Images/cover.jpg" id="cover.jpg" media-type="image/jpeg" />
    <item href="Text/Cover.xhtml" id="Cover.xhtml" media-type="application/xhtml+xml" />
    <item href="Text/Title.xhtml" id="Title.xhtml" media-type="application/xhtml+xml" />
  </manifest>
  <spine toc="ncx">
    <itemref idref="Cover.xhtml" />
    <itemref idref="Title.xhtml" />
    <itemref idref="Section0001.xhtml" />
    <itemref idref="Section0002.xhtml" />
  </spine>
  <guide>
    <reference href="Text/Cover.xhtml" title="Cover" type="cover" />
  </guide>
</package>

[DiapDealer]

The very first thing that came to my mind (and I say this with joy in my heart and a twinkle in my eye) when I saw this was:
"That's what Adrian Monk's xml files would look like."

That's a lovely OPF file.

[varlog]

Originally Posted by DiapDealer

That's a lovely OPF file.

I've had a bad day today. This made me me smile at last .

[PeterT]

Originally Posted by DiapDealer

That's a lovely OPF file.

Is this a new pickuip line? Care to come back to my place and see my OPF files?