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

@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).

@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.

• Maintainability/GROK - if you have suggestions I am open to looking at them and incorporating them into the pull request. Also see 701e922 and a42d0f4 which I think make it look better.
• correctness - I followed the order that was given in the normative section. I didn't see it say anywhere that there was a specific order they had to be in, and when parsing JSON you shouldn't need a particular order
• precision

  • VCHAR - unless you really want to get ugly ABNF rules, I don't see how you are going to specify that you have to escape the quotes in values.

  • case sensitive - good to know it is by default case INSENSITIVE. However, do we really want to force case senstivity for what are basically map keys? @ruebot, what are your thoughts on this?

@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 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.

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?

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).

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.

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.

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.

@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.

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?

@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.

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

@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.