search

bagit-profiles / bagit-profiles-specification

https://bagit-profiles.github.io/bagit-profiles-specification/
Other
35 stars 11 forks source link

adding ABNF section #24

Closed jscancella closed 4 years ago

jscancella commented 4 years ago

This Pull Request integrates #23 into the index.html.

ruebot commented 4 years ago

@jscancella can you provide some rationale and background for this PR so that folks reviewing and providing feedback can be better informed?

jscancella commented 4 years ago

@ruebot sure! ABNF is often used to auto generate code by many projects. This would those projects to automatically create code/software that integrates with the specification. Additionally, many RFC specifications like to have ABNF as it defines in a very concrete way a specification.

I think it is also just another way to communicate the specification and make sure there is no ambiguity in the specification that can cause problems later (like what happened in the BagIt specification).

jscancella commented 4 years ago

@tdilauro I will also be gone most of January and unable to work on this until I get back. Hopefully I can finish it before I leave.

tdilauro commented 4 years ago

@jscancella Ugh. I just wanted to get my vague concerns out there, but didn't mean to cause any undo stress. I'll try to have a look sooner rather than later, but have to balance family vacation time. If it doesn't work out, we can always iterate later.

@tdilauro I will also be gone most of January and unable to work on this until I get back. Hopefully I can finish it before I leave.

jscancella commented 4 years ago

@jscancella Ugh. I just wanted to get my vague concerns out there, but didn't mean to cause any undo stress. I'll try to have a look sooner rather than later, but have to balance family vacation time. If it doesn't work out, we can always iterate later.

Don't worry about it, family is more important especially this time of year. Look at it when you get a chance, but don't stress.

ruebot commented 4 years ago

case sensitivity

BagIt touches on the challenges here. Basically says it depends on the file system. But, JSON is case sensitive. Since a BagIt Profile is JSON, then a BagIt Profile is case sensitive, right?

jscancella commented 4 years ago

Maybe it didn't make it into the specification, but I remember talking about https://tools.ietf.org/html/rfc8493#section-6.1.1.1 with Chris Adams and how we should try and preserve case, but not force anyone to be case sensitive when looking up information. For instance, if we have a bag object and want to get a particular key in the bag-info we shouldn't be case sensitive. But when we go to write the bag-info (or other parts of the bag) we should preserve the case sensitivity entered and write it exactly the same out to file.

I looked at https://tools.ietf.org/html/rfc7159 but couldn't find where it says that strings are case sensitive. Only that they are required to test for equality (see section 8.3).

jscancella commented 4 years ago

Also I just found in ECMA-404

An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs. A name is a string. A single colon token follows each name, separating the name from the value. A single comma token separates a value from a following name. The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.

Perhaps I am not understanding, but from the wording above it seems it is up to the individual parsers to determine if the name is case sensitive.

ruebot commented 4 years ago

How about we just go with insensitive? It'd be consistent with what @acdha and your discussion points here, and we could punt to a future BagIt update. Though, it's kinda tough since we're trying a thread a needle between BagIt and JSON specs.

tdilauro commented 4 years ago

I think that's fine, but we should be explicit about it. Additionally, the current release of the validator and my recently committed PR are case sensitive.

ruebot commented 4 years ago

@jscancella @tdilauro do we need to create a separate issue for the case sensitivity, or should we just address it in this PR? Once we sort that out, we can create an issue for the validator.

jscancella commented 4 years ago

Unless I am misunderstanding I think it is resolved - make it case insensitive. I haven't seen any proposed updates on the forum for this either, so should we go ahead and merge it?

ruebot commented 4 years ago

@jscancella if you resolve the conflict, I'm happy to hit approve if everything looks good. Then you're welcome to merge and write your own commit message.

tdilauro commented 4 years ago

The latest validator is case sensitive. Shouldn't these be in sync?

ruebot commented 4 years ago

@tdilauro yeah, ideally they should be in sync. If either you have time, feel free to go for it. Otherwise, it might be a bit before I can get to it. I'll create an issue over on the validator repo.