-
Notifications
You must be signed in to change notification settings - Fork 14
2020.05.13 Community Meeting
Andrew Woods edited this page Jun 11, 2020
·
11 revisions
- 4pm BST / 11am EDT / 8am PDT
- https://lyrasis.zoom.us/my/vivo1
- or Telephone:
- US: +1 669 900 6833 or +1 646 876 9923
- Canada: +1 647 558 0588
- Australia: +61 (0) 2 8015 2088
- United Kingdom: +44 (0) 20 3695 0088
- Meeting ID: 812 835 3771
- International numbers available: https://zoom.us/u/MO73B
- Ben Cail
- Andrew Hankinson
- Neil Jeffries
- Julian Morley
- Joshua Westgard
- David Wilcox
- Peter Winckles
- Andrew Woods
- Community updates (introductions, updates, implementations, plans, etc)
- Editorial updates
- Mostly polish and validator work
- Commits since last community meeting
- Open questions
- Pending pull-requests
- Review of previous action items
- Releasing 1.0
- Requirements to release 1.0
- Status of fixture objects
- Status of validators
- Status of test suite - embedded in validators
- Open 1.0 Spec Issues
- Requirements to release 1.0
- OCFL Extensions
- Next community meeting: June 10, 2020 (second Wednesday of the month)
- Potentially rotate timing of the community call?
- Community Updates:
- David Wilcox will be doing a presentation on Fedora 6 at Virtual Samvera Connect, which will include OCFL
- Editorial Group Updates:
- Python validator is coming along
- Stanford will be moving forward with a ruby validator as well
- Validator work has helped to clarify certain issues around strictness (may/should/must, errors vs. warnings)
- Open issues:
- Regarding the case insensitivity of hashes, the consensus was that this should be a validation error
- Content paths must also not contain the elements that are already forbidden in logical paths
- Pull Requests:
- PR on conflicting logical paths was approved
- Andrew W. will look at updating the table of validator codes
- Extensions:
- The intent is for community members to be able to create extensions (this would be facilitated by a PR resolving issue #2 )
- Releasing 1.0
- Extensions themselves by definition should not be blockers to a 1.0 release
- Having an extensibility mechanism/pattern in place, however, would be important for 1.0
- Who: What
- Neil: Add language specific to extensions, specifically layouts and parameterization. ext-issue-2