PR fixes

specification/library-guidelines.md

@@ -50,40 +50,39 @@ It is also important that minimal implementation incurs as little performance pe
 
 ## SDK Implementation
 
-The SDK implementation is a separate (optional) dependency. When it is plugged in it substitutes the minimal implementation that is included in the API package (exact substitution mechanism is language dependent).
+SDK implementation is a separate (optional) dependency. When it is plugged in it substitutes the minimal implementation that is included in the API package (exact substitution mechanism is language dependent).
 
-SDK implements core functionality that is required for translating API calls into telemetry data that is ready for exporting. Here is how OpenTelemetry components look like when the SDK is enabled:
+SDK implements core functionality that is required for translating API calls into telemetry data that is ready for exporting. Here is how OpenTelemetry components look like when SDK is enabled:
 
 ![Full Operation Diagram](language-library-full.png)
 
 SDK defines an [Exporter interface](sdk-exporter.md). Protocol-specific exporters that are responsible for sending telemetry data to backends must implement this interface.
 
 SDK also includes optional helper exporters that can be composed for additional functionality if needed.
 
-Library designers need to define the language-specific Exporter interface based on [this generic specification](sdk-exporter.md). 
+Library designers need to define the language-specific `Exporter` interface based on [this generic specification](sdk-exporter.md). 
 
 ### Protocol Exporters
 
 Telemetry backend vendors are expected to implement [Exporter interface](sdk-exporter.md). Data received via Export() function should be serialized and sent to the backend in a vendor-specific way.
 
-Vendors are encouraged to keep protocol-specific exporters as simple as possible and achieve desirable additional functionality such as queuing, retrying using helpers provided by SDK.
+Vendors are encouraged to keep protocol-specific exporters as simple as possible and achieve desirable additional functionality such as queuing and retrying using helpers provided by SDK.
 
-End users should be given the flexibility of making many of the decisions regarding the queuing, retrying, tagging, batching functionality that make the most sense for their application. For example, if an application is deployed with a locally running Agent daemon, the end user may prefer to not have a Retrier since local daemon is highly available. As opposed to that an application may require a reliable delivery of telemetry data to a remote backend that has no guaranteed availability. The end user may choose to use a persistent local queue and a Retrier in this case.
+End users should be given the flexibility of making many of the decisions regarding the queuing, retrying, tagging, batching functionality that make the most sense for their application. For example, if an application's telemetry data must be delivered to a remote backend that has no guaranteed availability the end user may choose to use a persistent local queue and an `Exporter` to retry sending on failures. As opposed to that for an application that sends telemetry to a locally running Agent daemon, the end user may prefer to have a simpler exporting configuration without retrying or queueing. 
 
 
 ## Alternative Implementations
 
 The end-user application may decide to take a dependency on alternative implementation. 
 
-The SDK provides flexibility and extensibility that may be used by many implementations. Before developing an alternative implementation, please, review extensibility points provided by OpenTelemetry.
+SDK provides flexibility and extensibility that may be used by many implementations. Before developing an alternative implementation, please, review extensibility points provided by OpenTelemetry.
 
 An example use case for alternate implementations is automated testing. A mock implementation can be plugged in during automated tests. For example it can store all generated telemetry data in memory and provide a capability to inspect this stored data. This will allow the tests to verify that the telemetry is generated correctly. Language Library authors are encouraged to provide such mock implementation.
 
-Note that mocking is also possible by using the SDK and a Mock Exporter without needed to swap out the entire SDK. 
+Note that mocking is also possible by using SDK and a Mock `Exporter` without needed to swap out the entire SDK. 
 
 The mocking approach chosen will depend on the testing goals and at which point exactly it is desirable to intercept the telemetry data path during the test.
 
 ## Concurrency and Thread-Safety
 
-See [Concurrency and Thread-Safety](concurrency.md) specification for
-guidelines on what concurrency safeties should API implementations provide and how they should be documented.
+See [Concurrency and Thread-Safety](concurrency.md) specification for guidelines on what concurrency safeties should API implementations provide and how they should be documented.

specification/sdk-exporter.md

@@ -1,24 +1,24 @@
 # Exporter Interface
 
-Exporter defines the interface that protocol-specific exporters must implement so that they can be plugged into OpenTelemetry SDK and support sending of telemetry data.
+`Exporter` defines the interface that protocol-specific exporters must implement so that they can be plugged into OpenTelemetry SDK and support sending of telemetry data.
 
 The goals of the interface are:
 
-- Minimize burden of implementation for protocol-dependant telemetry exporters. The protocol exporter is expected to be primarily a simple telemetry data encoder and transmitter.
+- Minimize burden of implementation for protocol-dependent telemetry exporters. The protocol exporter is expected to be primarily a simple telemetry data encoder and transmitter.
 
-- Allow implementing helpers as composable components that use the same chainable Exporter interface. SDK authors are encouraged to implement common functionality such as queuing, batching, tagging, etc. as helpers. This functionality will be applicable regardless of what protocol exporter is used.
+- Allow implementing helpers as composable components that use the same chainable `Exporter` interface. SDK authors are encouraged to implement common functionality such as queuing, batching, tagging, etc. as helpers. This functionality will be applicable regardless of what protocol exporter is used.
 
 ## Interface Definition
 
-The exporter must support two functions: **Export** and **Shutdown**. In strongly typed languages typically there will be 2 separate Exporter interfaces, one that accepts spans (SpanExporter) and one that accepts metrics (MetricsExporter).
+The exporter must support two functions: **Export** and **Shutdown**. In strongly typed languages typically there will be 2 separate `Exporter` interfaces, one that accepts spans (SpanExporter) and one that accepts metrics (MetricsExporter).
 
 ### Export(batch)
 
 Exports a batch of telemetry data. Protocol exporters that will implement this function are typically expected to serialize and transmit the data to the destination.
 
 Export() will never be called concurrently for the same exporter instance. Export() can be called again only after the current call returns.
 
-Export() must not block indefinitely, there must be a reasonable upper limit after which the call must time out with an error result(typically CannotExport).
+Export() must not block indefinitely, there must be a reasonable upper limit after which the call must time out with an error result (typically CannotExport).
 
 **Parameters:**
 
@@ -32,13 +32,13 @@ ExportResult is one of:
 
 - Success - batch is successfully exported. For protocol exporters this typically means that the data is sent over the wire and delivered to the destination server.
 
-- BadData - batch contains bad data and cannot be sent. The caller must not retry exporting the same batch. The batch must be dropped.
+- FailedFatal - exporting failed. The caller must not retry exporting the same batch. The batch must be dropped. This for example can happen when the batch contains bad data and cannot be serialized.
 
-- CannotExport - cannot export to the destination. The destination is unavailable, network error or endpoint does not exist. The caller should record the error and may retry exporting the same batch after some time.
+- FailedRetryable - cannot export to the destination. The caller should record the error and may retry exporting the same batch after some time. This for example can happen when the destination is unavailable, there is a network error or endpoint does not exist. 
 
 ### Shutdown()
 
-Shutdowns the exporter. Called when the SDK is shutdown. This is an opportunity for exporter to do any cleanup required.
+Shuts down the exporter. Called when SDK is shut down. This is an opportunity for exporter to do any cleanup required.
 
 ## Further Language Specialization
 
@@ -48,7 +48,7 @@ Authors are encouraged to use efficient data structures on the interface boundar
 
 ### Examples
 
-These are examples on what the Exporter interface can look like in specific languages. Examples are for illustration purposes only. Language library authors are free to deviate from these provided that their design remain true to the spirit of Exporter concept.
+These are examples on what the `Exporter` interface can look like in specific languages. Examples are for illustration purposes only. Language library authors are free to deviate from these provided that their design remain true to the spirit of `Exporter` concept.
 
 #### Go SpanExporter Interface