Cleaned up README

Dimitri van Hees · Dimitri van Hees · commit 847c7005dca7 · 2017-01-26T15:46:12.000+01:00
diff --git a/README.md b/README.md
@@ -1,26 +1,28 @@
 # Open Cloud Mesh API Specification
 
-This repository contains the [OpenAPI](https://github.com/OAI/OpenAPI-Specification) (fka Swagger) specification for the Open Cloud Mesh API. Please note that this is work-in-progress.
+![Open Education API](logo.png)
 
-* [Roadmap](#roadmap)
-* [Documentation](#documentation)
-* [Contributing](#contributing)
+This repository contains the [OpenAPI](https://github.com/OAI/OpenAPI-Specification) (fka Swagger) specification for the Open Cloud Mesh API. This specification describes the RESTful API endpoints which vendors should support to make sharing of resources between different vendors possible.
 
-## Roadmap
+* [Scope and assumptions](#scope-and-assumptions)
+* [API Documentation](#api-documentation)
+* [Contributing](#contributing)
 
-The current version is unfinished yet. Currently in progress: 
+## Scope and assumptions
 
-* ~~Convert [existing documentation](http://lukasreschke.github.io/OpenCloudMeshSpecification/#sending-a-share-offer) to Open API Specification~~
-* ~~Discuss points of improvement for the new spec~~
-* ~~Finalize specification conforming v1.0 document~~
+* Provider knows the consumer (both endpoint and user) when it creates a share with the consumer (#26). How this is known is not part of this spec.
+* Consumer doesn't have to accept a share, the resource will be available to the consumer immediately (#25).
+* Dealing with incoming shares is a vendor specific implementation. One vendor might use an 'accept before' process while another vendor might use a 'decline after' approach. This is considered part of the UX and thus not part of the interaction between different vendors. The consumer could send a notification though, t 
+* Reverting access to outgoing shares is a vendor specific implementation. One vendor might delete an entire share while another might invalidate an access token. This is considered part of venor specific internals and thus not part of the intraction between different vendors.
+* The actual file sync isn't a part of this specification. To keep this specification 'future proof', the file sync protocol will be embedded as a separate object in Open Cloud Mesh API calls. This protocol object contains all protocol specific options, e.g. WebDAV specific options.
 
-## Documentation
+## API Documentation
 
-The WIP specification can be rendered as HTML documentation:
+The specification can be rendered as HTML documentation using [ReDoc](https://github.com/Rebilly/ReDoc):
 
-* [API Reference Documentation](https://docs.apiwise.nl/ocm/index.html)
+* [API Reference Documentation](https://rawgit.com/GEANT/OCM-API/docs.html)
 
 ## Contributing
 
-The Open Cloud Mesh API is an open source, community-driven project. If you'd like to contribute, please follow the [Contributing Guidelines](CONTRIBUTING.md).
+The Open Cloud Mesh API specification is an open source, community-driven project. If you'd like to contribute, please follow the [Contributing Guidelines](CONTRIBUTING.md).
 
diff --git a/docs.html b/docs.html
@@ -0,0 +1,21 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Open Cloud Mesh API Reference Documentation</title>
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+    <style>
+      body {
+        margin: 0;
+        padding: 0;
+      }
+
+      api-logo {
+        margin: 20px 0;
+      }
+    </style>
+  </head>
+  <body>
+    <redoc spec-url="spec.yaml"></redoc>
+    <script src="https://rebilly.github.io/ReDoc/releases/latest/redoc.min.js"></script>
+  </body>
+</html>
diff --git a/logo.png b/logo.png
diff --git a/spec.yaml b/spec.yaml
@@ -4,7 +4,7 @@ info:
   description: Open Cloud Mesh Open API Specification.
   version: 0.0.3
   x-logo:
-    url: https://docs.apiwise.nl/ocm/logo.jpg
+    url: logo.png
 schemes:
   - https
 consumes:
