Closed kba closed 5 years ago
@mjordan let me know if you're good with this, and we can merge.
We probably should be consistent with the standard Bagit Python library. From what I can tell, it handles Bagit version typecasting at https://github.com/LibraryOfCongress/bagit-python/blob/master/bagit.py#L342. So, numeric.
@mjordan this is for the spec, not the validator. I think this lines up fine with the BagIt spec. If we want to go a bit further, we could have it say, SHOULD be a UTF-8 encoded string
.
True but the library expects versions as strings and parses them as
self.version_info = tuple(int(i) for i in self._version.split(".", 1))
So, version numbers must not only be strings but consist of two dot-concatenated integer sequences?
Ah, sorry, am instructing at Islandora Camp... SHOULD be a UTF-8 encoded string
sounds sufficient.
Are we in agreement that the updated language here should be:
A list of BagIt version numbers that will be accepted. At least one version number is required. All version numbers MUST be UTF-8 encoded strings.
A list of BagIt version numbers that will be accepted. At least one version number is required. All version numbers MUST be UTF-8 encoded strings.
Done.
The
Accept-BagIt-Version
field must contain a list of strings.Because
0.96
,0.97
or1.0
(but not1.1.0
obviously) are also valid floats in JSON, I did not realize we had a weird error in our profile for bags with (correctly typed) stringBagIt-Version
fields.