Open glenrobson opened 3 years ago
Good changes. These look much better than my last view. I think this is a good model for highlighting single use properties like this.
Note there was a useful discussion in the TRC call on this issue:
https://docs.google.com/document/d/1j_zrkkxhf5b1bMxwEAtwo5Se6D0qqNXAKpawbRURihg/edit?usp=sharing
But the outcome was that there was a suggestion that we should raise the issue with the UV about converting the navDate
to the viewers local time. Instead we think it should show the time specified in the manifest. We can ask the UV folks if this was a deliberate choice for a use case we haven't thought about but at this time we think its a bug.
If it is agreed with the UV folks it is a bug we can create an API issue to add client guidance to the specifications to say that this date shouldn't be converted to the viewers time zone.
In the TRC meeting we didn't think the recipe needed to change.
I have created the UV issue here: https://github.com/UniversalViewer/universalviewer/issues/784
(Noting for the record that I 👍ed my own recipe)
+1: 24 [azaroth42 cubap emulatingkat glenrobson hadro irv jonhartzler jtweed julsraemy kirschbombe ksclarke markpatton mattmcgrattan mcwhitaker mikeapp mixterj mposton-folger nfreire regisrob rentonsa thehabes tpendragon triplingual zimeon] 0: 0 [] -1: 0 [] Not TRC: 0 [] Ineligible: 0 []
Super majority is in favor, issue is approved
🕺🏼
Links
Background and Summary
This recipe explains the use of the navDate property and how it can be used to order and navigate between two manifests which are part of a collection. It is a supporting recipe to the Newspapers recipe but just focuses on the use and experience of navDate rather than going into all of the other Newspaper specific features.
The recipe includes guidance on how to deal with non-specific dates by repeating guidance from the IIIF Presentation API version 2 spec that was taken out of version 3. During the writing of this recipe we discovered a few anomalies with how non-specific dates are implemented in some viewers which would be useful to discuss.
Voting and changes
We welcome comments on the recipe and as well as voting +1, confused face or -1 feel free to add comments to this issue. If this issue is approved then the author will take account of the comments before we merge the branch in to the master cookbook branch.
If the recipe is rejected by the TRC then we will make the changes requested and resubmit it to a future TRC meeting. If you feel that your comments are substantial enough that the recipe should be looked at again by the TRC after the changes have been made please vote -1 (thumbs down).
Changes to the recipe will only be made after the TRC voting process has concluded.