[arrow] branch master updated: [Doc] Fix typos in implementation guidelines

[we...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

wesm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/arrow.git


The following commit(s) were added to refs/heads/master by this push:
     new 65191c9  [Doc] Fix typos in implementation guidelines
65191c9 is described below

commit 65191c99808f5ab443ee32db3d5c4da4305360a0
Author: b-rms <39...@users.noreply.github.com>
AuthorDate: Wed Aug 14 12:05:42 2019 -0700

    [Doc] Fix typos in implementation guidelines
    
    - `can implements` -> `can implement`
    - added missing period
    - added missing comma
---
 docs/source/format/Guidelines.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/source/format/Guidelines.rst b/docs/source/format/Guidelines.rst
index 5b03220..4d4ffd5 100644
--- a/docs/source/format/Guidelines.rst
+++ b/docs/source/format/Guidelines.rst
@@ -18,7 +18,7 @@
 Implementation guidelines
 =========================
 
-An execution engine (or framework, or UDF executor, or storage engine, etc) can implements only a subset of the Arrow spec and/or extend it given the following constraints:
+An execution engine (or framework, or UDF executor, or storage engine, etc) can implement only a subset of the Arrow spec and/or extend it given the following constraints:
 
 Implementing a subset the spec
 ------------------------------
@@ -33,11 +33,11 @@ If consuming and producing vectors
 
 There is a minimal subset of vectors to be supported.
 Production of a subset of vectors and their corresponding metadata is always fine.
-Consumption of vectors should at least convert the unsupported input vectors to the supported subset (for example Timestamp.millis to timestamp.micros or int32 to int64)
+Consumption of vectors should at least convert the unsupported input vectors to the supported subset (for example Timestamp.millis to timestamp.micros or int32 to int64).
 
 Extensibility
 -------------
 
-An execution engine implementor can also extend their memory representation with their own vectors internally as long as they are never exposed. Before sending data to another system expecting Arrow data these custom vectors should be converted to a type that exist in the Arrow spec.
+An execution engine implementor can also extend their memory representation with their own vectors internally as long as they are never exposed. Before sending data to another system expecting Arrow data, these custom vectors should be converted to a type that exist in the Arrow spec.
 An example of this is operating on compressed data.
 These custom vectors are not exchanged externally and there is no support for custom metadata.