-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify "same object state" of version block (E066) #571
Comments
Let's say your versions block for v1 of an object looks like the following: "versions": {
"v1": {
"created": "2018-10-02T12:00:00Z",
"message": "version one",
"state": {
"7545b8...f67": [ "file.txt" ],
"12b348...9ac": [ "file2.txt" ]
},
"user": {
"address": "alice@example.org",
"name": "Alice"
}
}
} I believe that section of spec is to ensure that later versions don't do something like the following: "versions": {
"v1": {
"created": "2018-10-02T12:00:00Z",
"message": "version one",
"state": {
"7545b8...f67": [ "file2.txt" ],
"12b348...9ac": [ "file.txt" ]
},
"user": {
"address": "alice@example.org",
"name": "Alice"
}
},
"v2": {
"created": "2018-10-02T12:00:00Z",
"message": "version two",
"state": {
"7545b8...f67": [ "file2.txt" ],
"12b348...9ac": [ "file.txt" ],
"3b456a...111": [ "file3.txt" ]
},
"user": {
"address": "alice@example.org",
"name": "Alice"
}
}
} In this case, both the v1 and v2 inventories would validate in isolation. However, the v2 inventory is invalid by I think the text that you suggested is too focused on accounting for the case where the inventory digest algorithm changes, which is not necessary for there to be a violation of |
Thanks for the response @pwinckles. Do you think the language of The concern I have is that it's easy for validator authors to misinterpret this part of the spec as saying that the json for version states should be equivalent across inventories -- or to otherwise misinterpret "same object state." (that's based on personal experience 😀). |
Yes, I agree that the intent of "same object state" could be more clear. |
When/if this is addressed, perhaps the question of unicode normalization could also be addressed? As noted in point three in #559:
|
I think this situation might be clearer if we changed the spec to say:
because we define "logical state" as logical paths tied to bitstreams, not dependent upon the digest algorithm, whereas "object state" is not formally defined. I agree that changes in digest algorithm between inventories are fine, and do not create a problem meeting this condition. For example, the approach my validator code uses to check for (I do also have code that provides extra debugging info using digest values, in the case that the digest algorithms do match between versions, but that isn't necessary to detect an error) |
I have a question about this line from the spec:
As I understand it, the digest algorithm can change from one inventory to the next, which means the digests in the version blocks can change. If that's true, then isn't the sense of "sameness" in this statement somewhat ambiguous? I think it may help to explain what makes two version blocks the same, even when the digests may differ. Something like this: The same byte stream used for a given digest in the version block of the prior inventory must be used to generate the corresponding digest in the version block on the new inventory.
The text was updated successfully, but these errors were encountered: