Resolve build

Author: thompson-tomo

docs/messaging/messaging-spans.md

@@ -73,10 +73,10 @@ linkTitle: Spans
 
 Although messaging systems are not as standardized as, e.g., HTTP, it is assumed that the following definitions are applicable to most of them that have similar concepts at all (names borrowed mostly from JMS):
 
-A *message* is an envelope with a potentially empty body.
+A _message_ is an envelope with a potentially empty body.
 This envelope may offer the possibility to convey additional metadata, often in key/value form.
 
-A message is sent by a message *producer* to:
+A message is sent by a message _producer_ to:
 
 - Physically: some message _broker_ (which can be e.g., a single server, or a cluster, or a local process reached via IPC). The broker handles the actual delivery, re-delivery, persistence, etc. In some messaging systems the broker may be identical or co-located with (some) message consumers.
   With Apache Kafka, the physical broker a message is written to depends on the number of partitions, and which broker is the _leader_ of the partition the record is written to.
@@ -143,13 +143,13 @@ for similar scenarios such as load-balancing or broadcasting.
 
 ### Conversations
 
-In some messaging systems, a message can receive one or more reply messages that answers a particular other message that was sent earlier. All messages that are grouped together by such a reply-relationship are called a *conversation*.
-The grouping usually happens through some sort of "In-Reply-To:" meta information or an explicit *conversation ID* (sometimes called *correlation ID*).
+In some messaging systems, a message can receive one or more reply messages that answers a particular other message that was sent earlier. All messages that are grouped together by such a reply-relationship are called a _conversation_.
+The grouping usually happens through some sort of "In-Reply-To:" meta information or an explicit _conversation ID_ (sometimes called _correlation ID_).
 Sometimes a conversation can span multiple message destinations (e.g. initiated via a topic, continued on a temporary one-to-one queue).
 
 ### Temporary and anonymous destinations
 
-Some messaging systems support the concept of *temporary destination* (often only temporary queues) that are established just for a particular set of communication partners (often one to one) or conversation.
+Some messaging systems support the concept of _temporary destination_ (often only temporary queues) that are established just for a particular set of communication partners (often one to one) or conversation.
 Often such destinations are also unnamed (anonymous) or have an auto-generated name.
 
 ## Conventions
@@ -169,7 +169,7 @@ not help in correlating producers with consumers. To be able to directly
 correlate producers with consumers, another context that is propagated with
 the message is required.
 
-A message *creation context* allows correlating producers with consumers
+A message _creation context_ allows correlating producers with consumers
 of a message and model the dependencies between them,
 regardless of the underlying messaging transport mechanism and its instrumentation.
 

docs/rpc/rpc-metrics.md

@@ -57,7 +57,7 @@ metrics can be filtered for finer grain analysis.
 The following metric instruments MUST be used to describe RPC operations. They
 MUST be of the specified type and units.
 
-*Note: RPC server and client metrics are split to allow correlation across client/server boundaries, e.g. Lining up an RPC method latency to determine if the server is responsible for latency the client is seeing.*
+_Note: RPC server and client metrics are split to allow correlation across client/server boundaries, e.g. Lining up an RPC method latency to determine if the server is responsible for latency the client is seeing._
 
 ### RPC server
 

docs/rpc/rpc-spans.md

@@ -52,7 +52,7 @@ This document defines how to describe remote procedure calls
 
 ### Span name
 
-The *span name* MUST be the full RPC method name formatted as:
+The _span name_ MUST be the full RPC method name formatted as:
 
 ```
 $package.$service/$method
@@ -366,7 +366,7 @@ In the lifetime of an RPC stream, an event for each message sent/received on cli
 
 HTTP calls can generally be represented using just [HTTP spans](/docs/http/http-spans.md).
 If they address a particular remote service and method known to the caller, i.e., when it is a remote procedure call transported over HTTP, the `rpc.*` attributes might be added additionally on that span, or in a separate RPC span that is a parent of the transporting HTTP call.
-Note that *method* in this context is about the called remote procedure and *not* the HTTP verb (GET, POST, etc.).
+Note that _method_ in this context is about the called remote procedure and _not_ the HTTP verb (GET, POST, etc.).
 
 ## Semantic conventions for specific RPC technologies