-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Unix ls
discussion to implementation-notes
#304
Comments
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>
.
|
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 |
* Add note about zero padding not being recommended * Fix typo Fixes #304
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:The text was updated successfully, but these errors were encountered: