Repository navigation
Non-unique unique identifiers and reading system conformance #1310
Description
Reading Systems MUST NOT depend on the Unique Identifier being unique to one and only one EPUB Publication. Determining whether two EPUB Publications with the same Unique Identifier represent different versions of the same publication (see Release Identifier), or different publications, might require inspecting other metadata, such as the titles or authors.
I'm trying to figure out how to write a test for this—create two different books with the same unique ID and make sure that two books show up in the RS UI? Should this be normative text? In some sense this reads more like non-normative advice to reading systems. In general we say nothing about how reading systems present different publications to users, or how reading systems respond to updated versions of the same content.
Activity
dauwhe commentedon Feb 20, 2020
See also #779
GarthConboy commentedon Feb 20, 2020
Your "two show up" seems a fine test. But, yes, I could also fall for non-normative.
iherman commentedon Dec 18, 2020
The issue was discussed in a meeting on 2020-12-18
List of resolutions:
View the transcript
2. release identifier construction
See github issue #1440.
Dave Cramer: Need to do some boring stuff called work.
… The release identifier comes up from time to time (id + release time).
… So you can figure out new vs update.
… This is really just advice to RSes on how to distinguish books.
… So really hard to test. How do you determine if there was an error?.
… Should this be in the appendix non-normatively?.
Ivan Herman: Is it used ever by anyone?.
Dave Cramer: That is my favorite question.
Hadrien Gardeur: Partial reply: There are roughly 2 groups of RSes.
… one where content always comes from a controlled warehouse (eg big retailers).
… second is more generic that can support any type of epub.
See github issue #1310.
Hadrien Gardeur: this id makes more sense for the second group.
… We are talking about unique id, but also saying maybe it isn't unique, so maybe don't rely on it. Very confusing for RS.
… we are building a spec that should work for all types of RSes.
… Personally know that some RSes in the second group do use that id.
… Recs about looking at title is often wrong (eg if the change was to fix the title).
Garth Conboy: We are mostly a retailer, but also allow side loading. We ignore both the UID and the mod date-time..
Ivan Herman: Need to be careful, there are two notions the UID and the release ID.
… This creates an identifier based on some info in the epub.
… this issue is whether that algo makes sense.
Hadrien Gardeur: If this is specifically about release id, then I don't know who is using it.
… UID is different answer.
Dave Cramer: Not discussing removal of id or release date.
… This is about uniqueness of UID, what happens when two books have the same UID, etc.
… We probably don't want to start dictating how RSes present their libraries.
… I would say we remove this concept since it can't really be tested.
Ken Jones: Maybe have a revision number?.
… to make it clear there is id and version explicitly.
Hadrien Gardeur: But that is the issue at stake.
… epub 2 only had uid.
… this was added in epub 3, but isn't really used.
… first group doesn't really care, and second group doesn't handle versioning at all.
… don't think we should be in the business of specifying how these are used.
… Would like to not say anything about UID, just say what it is and leave it to the RS implementors to figure it out.
Zheng Xu (徐征): Will be very difficult to test something that is undefined.
Tzviya Siegman: Want to caution about versions and revisions.
… Not changing too much in the spec is good guidance.
… There has been a lot of discussion about rev vs version, don't want to take it up here.
Gregorio Pellegrino: Publishers don't seem to use this, we use ISBN and file hashes.
Garth Conboy: We seem to agree that release ID is not really used, and even if it is doesn't need to be in the spec.
… So we seem to agree on this issue.
Dave Cramer: Makes sense. We won't comment on metadata construction in the specs.
… proposal would be to remove that language without touching required metadata.
Ivan Herman: Need to be careful about how this is phrased.
… are we proposing removal or moving to non-normative section/document.
… Also DC terms has a
hasVersionterm, so we have that too.… May want to mention it, but no reason why it couldn't just be used.
… But I propose that dauwhe propose something.
Dave Cramer: [typing noises].
Dave Cramer: I don't there is a compat issue here.
… don't think there is any testable change here.
… This is basically editorial.
Ivan Herman: We can say any valid 3.2 will be valid with 3.3, this change does not alter that.
… Doesn't change behavior or authoring.
Dave Cramer: Resolved!.
iherman commentedon Dec 18, 2020
The issue was discussed in a meeting on 2020-12-18
List of resolutions:
View the transcript
3. Non-unique unique identifiers and reading system conformance
See github issue #1310.
Dave Cramer: the spec says "Reading Systems MUST NOT depend on the Unique Identifier being unique to one and only one EPUB Publication. Determining whether two EPUB Publications with the same Unique Identifier represent different versions of the same publication (see Release Identifier), or different publications, might require inspecting other metadata, such as the titles or authors.".
… Has no idea how to test this.
… Just make two books with the same UID and see what happens?.
… Seems like implementation advice.
… Would not be sad to see this go away.
Garth Conboy: Concept is useful, maybe turn must to should, remove ref to release id and declare victory.
Ivan Herman: Need to be careful about testability being the only criteria.
Ivan Herman: when it comes to metadata, we can't necessarily depend on testability.
… since, e.g., libraries want metadata for their purposes we can't test, but we may still want to require it.
… That is a general comment on using testable as a criteria.
Wendy Reid: Think it is the case that we have more bad uids than correct ones.
… Create our own uids since they are better than what we get.
Dave Cramer: Maybe move to a note?.
… non-normatively.
… Which also solves the testing issue.
Dave Cramer: And cleans up the spec a bit.
Bill Kasdorf: We have a combo of a spec with recommended practice.
… These are often kept separate, prefer that since it keeps the spec only a spec, and allows for updating recs more easily.
Ivan Herman: Trying to reconcile this. We have to be consistent with all the metadata.
… For instance author must be correct, but that is also untestable.
… May need to clarify for all metadata that it is required, and there is an implicit must, and give a blanket statement that any of it could be wrong.
Tzviya Siegman: As a publisher, the way the metadata is currently is very clear.
… and while it is processed in different ways, this is a very easy part of the spec to understand.
… One major complaint is the spec is already too broken up.
… don't want to add to that.
Hadrien Gardeur: prefer to make non-normative and also revisit the text overall.
… don't think it needs to exist at all.
Dave Cramer: Two proposals: 1 make it non-normative or 2 remove entirely.
Garth Conboy: If we make it non-normative it might be rewritten.
Dave Cramer: vote 1 for non-normative, 2 for remove, 0 to abstain.
George Kerscher: 2.
Ivan Herman: Can we agree to make non-normative and request new, shorter text?.
… then vote on the new text later.
all: rumblings of assent.
Garth Conboy: Volunteer audio books time slot. Something about moving back two hours.
Dave Cramer: Thanks for actual progress!.
mattgarrish commentedon Jan 22, 2021
Could someone who attended this meeting clarify what was meant by "shorter text"? I can't find reference to what specifically is unwanted.
My guess would be to replace the cited paragraph with a note along these lines:
Or is that too vague?
mattgarrish commentedon Mar 5, 2021
Anyone want to weigh in on this?
Change in RS conformance on unique identifier
iherman commentedon Mar 8, 2021
(Admin) trying to relocate the open parts of the discussions above
dc:identiferentry MUST be part of the metadata and that theunique-identifierMUST refer to this element. These are testable, and do make sense (I believe whether theunique-identifieris necessary has been discussed, and we agreed this should stay).The question is what to do with (1), ie, the relevant section in the RS spec. The resolution is that this text should not be normative.
See PR #1560 for that one.