Closed jonathanrobie closed 3 years ago
Can't it just look at the date/time of the SB?
Suppose I create a new Scripture Burrito, but nothing in the contents has changed. What should happen?
On Thu, Jul 30, 2020 at 11:15 AM Tim Steenwyk notifications@github.com wrote:
Can't it just look at the date/time of the SB?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-666444535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPMCABW5ZVJALKYNOSLR6GFB7ANCNFSM4PN4OYMA .
If you mean what should happen as far as identification is concerned, then I would think the project identification and revision of both burritos would be the same. The fact that they have different dates shouldn't matter much as far as DBL is concerned. DBL would just accept it as another revision and it would happen to have the same contents as the previous revision.
Tim Steenwyk
Software developer SIL Language Software Development tim_steenwyk@sil.org
On Thu, Jul 30, 2020 at 3:39 PM Jonathan Robie notifications@github.com wrote:
Suppose I create a new Scripture Burrito, but nothing in the contents has changed. What should happen?
On Thu, Jul 30, 2020 at 11:15 AM Tim Steenwyk notifications@github.com wrote:
Can't it just look at the date/time of the SB?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-666444535 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AANPTPMCABW5ZVJALKYNOSLR6GFB7ANCNFSM4PN4OYMA
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-666638989, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAIVTCIZC5EJFTQGWFSTZLR6HD6NANCNFSM4PN4OYMA .
Lots of possibilities here but I think that SB spec currently supports enough ways to do this currently (including checksums on ingredients).
In DBL currently, it's DBL that assigns a revision number (revision of previous entry with same PT project ID + 1). Dates are not considered (although we capture the date that it's received), for the same reason that you can't compare files on disk using creation date.
If we're going to have a single identification section, then it's important that (e.g.) PT puts a revision identifier that's unambiguous
This is really a question of integrity constraints with respect to the identifier. If two burritos are identified as "the same" but their contents differ, there's a problem with referential integrity.
The specification should clearly tell us how to identify (1) two revisions of the same project, (2) two burritos that both represent the same revision of the same project. Given two burritos for the same project, it should be easy to know which is newer. I think it should probably tell us this: the systemId provides the identifier and revision number, if two burritos have the same systemId (including revision) then they should have the same content, if not, all bets are off (semantics are undefined according to our specification).
Revision numbers are comparable, a larger number is considered later than a smaller number.
"systemId": {
"dbl": {
"id": "2880c78491b2f8ce",
"revision": "91"
}
},
On Thu, Nov 5, 2020 at 12:05 PM Jesse Griffin notifications@github.com wrote:
Assigned #208 https://github.com/bible-technology/scripture-burrito/issues/208 to @jonathanrobie https://github.com/jonathanrobie.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#event-3963461451, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPJUYSPBG6QWH4VEVV3SOLLL5ANCNFSM4PN4OYMA .
Narrative:
Paratext creates a burrito and uploads to the DBL with a systemId like so;
"ptx": {
"id": "ksdjoiejfs",
"revision": "ljksdfo8jkm",
"timestamp": "2020-11-19-11:30"
}
DBL receives that and adds it's own DBL systemId:
"dbl": {
"id": "2880c78491b2f8ce",
"revision": "1"
}
now, DBL receives another upload like this:
"ptx": {
"id": "ksdjoiejfs",
"revision": "ljsdf8",
"timestamp": "2020-11-19-11:18"
}
DBL creates a new revision like so (even though the most recent upload is from an earlier Paratext commit):
"dbl": {
"id": "2880c78491b2f8ce",
"revision": "1"
}
Suggestion is that we add a timestamp field to idAuthority. The timestamp should reflect the idAuthority's revision control system, e.g. the timestamp of the revision noted.
Is the timestamp required or optional? (in the narrative, it's not always present)
Is this timestamp for the overall SB sufficient for this use case?
In my review of the spec and the suggestion here, I think we should include timestamp as an optional field in idAuthority. I can see how it would be useful for an app to be able to see that information for each idAuthority that is listed.
I think the timestamp is sufficient. Any reason not to make it required?
Jonathan
On Mon, Dec 14, 2020 at 1:18 PM Jesse Griffin notifications@github.com wrote:
In my review of the spec and the suggestion here, I think we should include timestamp as an optional field in idAuthority. I can see how it would be useful for an app to be able to see that information for each idAuthority that is listed.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-744620736, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPICBYT3KFT5GRRQFP3SUZJIRANCNFSM4PN4OYMA .
@jonathanrobie which timestamp are you referring to in your comment?
This timestamp:
"ptx": { "id": "ksdjoiejfs", "revision": "ljksdfo8jkm", "timestamp": "2020-11-19-11:30" }
On Tue, Dec 15, 2020 at 4:27 PM Jesse Griffin notifications@github.com wrote:
@jonathanrobie https://github.com/jonathanrobie which timestamp are you referring to in your comment?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-745578244, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPJ4VP36PWYYOSPNY2TSU7IEPANCNFSM4PN4OYMA .
Agreed today that we will make this required.
I've captured the action on the spec in #234. Close this issue?
Further discussion may happen in #235 .
Implementation Need
Suggestion is that we add a timestamp field to idAuthority. The timestamp should reflect the idAuthority's revision control system, e.g. the timestamp of the revision noted.
See more details below.
History
An editor like Paratext has created a new revision. The user wants to synchronize with the DBL server. The server has received the Burrito and wants to know if it is new or an existing resource.
How is this done?
One possible approach: