fixed links to point to 1.0 spec (#47)

Co-authored-by: Peter Winckles <[email protected]>

docs/0003-hash-and-id-n-tuple-storage-layout.md

@@ -81,7 +81,7 @@ decoded, because the truncation may leave a partial encoding at the end of the
 
 `digestAlgorithm` is defaulted to `sha256`, and it MUST either contain a digest
 algorithm that's [officially supported by the OCFL
-spec](https://ocfl.io/draft/spec/#digest-algorithms) or defined in a community
+specification](https://ocfl.io/1.0/spec/#digest-algorithms) or defined in a community
 extension. The specified algorithm is applied to OCFL object identifiers to
 produce hex encoded digest values that are then mapped to OCFL object root
 paths.

docs/0004-hashed-n-tuple-storage-layout.md

@@ -65,7 +65,7 @@ an object may only be found within its `inventory.json`.
 
 `digestAlgorithm` is defaulted to `sha256`, and it MUST either contain a digest
 algorithm that's [officially supported by the OCFL
-spec](https://ocfl.io/draft/spec/#digest-algorithms) or defined in a community
+specification](https://ocfl.io/1.0/spec/#digest-algorithms) or defined in a community
 extension. The specified algorithm is applied to OCFL object identifiers to
 produce hex encoded digest values that are then mapped to OCFL object root
 paths.

docs/0005-mutable-head.md

@@ -285,7 +285,7 @@ but they can differ based on inventory file settings.
 
 When an object does not have an active mutable HEAD, then a new mutable version
 is created following similar steps as outlined in the [OCFL implementation
-notes](https://ocfl.io/draft/implementation-notes/#an-example-approach-to-updating-ocfl-object-versions)
+notes](https://ocfl.io/1.0/implementation-notes/#an-example-approach-to-updating-ocfl-object-versions)
 with two notable differences.
 
 1. The content paths of newly added files must be relative to