Add Unix ls discussion to implementation-notes

[zimeon]

Split from #281: we have agreed to add a discussion of zero padding and lexical sorting in Unix ls to the implementation-notes. See also #2. I propose something like the following as a new paragraph to 3.2.1 Version Numbering:

Systems with version directories have often used zero-padding in order to show version order with common lexical sorting tools (such as Unix ls). Zero-padding is not recommended in order to avoid having to make arbitrary choices of padding length or to place limits of the number of versions supported. In archival storage use cases, objects with more than 9 versions are rare, and while it is important that manual OCFL object be possible, it is not expected to be the norm. OCFL-aware tools can, of course, easily sort unpadded version directories in version order.

[birkland]

There seems to be an emphasis on human readability in the spirit of the ocfl spec, the "not expected to be the norm" clause seems to cause tension with that spirit. In addition, while the spec is deliberately non-scalable with respect to large numbers of versions (and low version counts are likely truly the norm), the claim of < 9 versions being the specific norm seems to conflict with the warning about running out of version space when padded. So in that light, I think this paragraph can end at "limits on the number of versions supported"

…

On Thu, Feb 14, 2019, 6:07 AM Simeon Warner ***@***.*** wrote: Split from #281 <#281>: we have agreed to add a discussion of zero padding and lexical sorting in Unix ls to the implementation-notes <https://ocfl.io/draft/implementation-notes/>. See also #2 <#2>. I propose something like the following as a new paragraph to 3.2.1 Version Numbering <https://ocfl.io/draft/implementation-notes/#version-numbering>: Systems with version directories have often used zero-padding in order to show version order with common lexical sorting tools (such as Unix ls). Zero-padding is not recommended in order to avoid having to make arbitrary choices of padding length or to place limits of the number of versions supported. In archival storage use cases, objects with more than 9 versions are rare, and while it is important that manual OCFL object be possible, it is not expected to be the norm. OCFL-aware tools can, of course, easily sort unpadded version directories in version order. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#304>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfm-T_FgScvSanM3Dnl7pBVKw0TV9ibks5vNUNdgaJpZM4a7W1V> .

[ahankinson]

I would agree with @birkland. We only have limited data about what constitutes the 'norm' in versioning, since we've been largely basing this assumption on experiences with Moab.

GNU ls does support lexographical ordering with ls -v; With BSD ls the output can be piped through sort, ls | sort -n. So I think we can still achieve lexographical ordering with built-in OS tools without going into too much detail or recommending a problematic (and permanent) change to version numbering.