diff --git a/docs/dev/synchronizers.md b/docs/dev/synchronizers.md
index c215492..ee0993d 100644
--- a/docs/dev/synchronizers.md
+++ b/docs/dev/synchronizers.md
@@ -1,9 +1,9 @@
 # Writing Synchronizers
 
-Synchronizers are the component of CORD that map the abstract declarative state about how the system is suppose to behave (as defined by the XOS data model) into the concrete operational state of the backend components that implement the system (e.g., VNFs, micro-services, SDN control applications). 
+Synchronizers are the components of CORD that map the abstract declarative state about how the system is suppose to behave (as defined by the XOS data model) into the concrete operational state of the backend components that implement the system (e.g., VNFs, micro-services, SDN control applications).
 
-Writing a Synchronizer is half of work required to on-board a service into CORD. First a model for the service is written as an [xproto](dev/xproto.md) specification, and then you implement a synchronizer that translates that model onto some backend component.
+Writing a Synchronizer is half of the work required to on-board a service into CORD. First a model for the service is written as an [xproto](xproto.md) specification, and then you implement a synchronizer that translates that model onto some backend component.
 
-To implement a Synchronizer, it is important to first understand the role they play in the CORD and the assumptions made about their behavior. The next section describes a set of [design guidelines](sync_arch.md) and the following one presents the
+To implement a Synchronizer, it is important to first understand the role they play in CORD and the assumptions made about their behavior. The next section describes a set of [design guidelines](sync_arch.md) and the following one presents the
 [implementation details](sync_impl.md).
 
diff --git a/docs/dev/xproto.md b/docs/dev/xproto.md
index cde5ad9..2468159 100644
--- a/docs/dev/xproto.md
+++ b/docs/dev/xproto.md
@@ -2,7 +2,7 @@
 
 XOS defines a language for specifying data models (_xproto_) and a tool chain for generating code based on the set of models (_xosgen_).
 
-The xproto language is based on Google’s protocol buffers (protobufs), borrowing their syntax, but extending their semantics to express additional behavior. Although these extensions can be written in syntactically valid protobufs (using the protobuf option feature), the resulting model definitions are cumbersome and the semantics are under-specified. 
+The xproto language is based on [Google’s protocol buffers](https://developers.google.com/protocol-buffers/) (protobufs), borrowing their syntax, but extending their semantics to express additional behavior. Although these extensions can be written in syntactically valid protobufs (using the protobuf option feature), the resulting model definitions are cumbersome and the semantics are under-specified.
 
 Whereas protobufs primarily facilitate one operation on models, namely, data serialization, xproto goes beyond protobufs to provide a framework for implementing custom operators.