anchor.diff:  ===== Server Span tags
   Spans created for incoming requests will have the following tags added by default:
   
  -* Tags.SPAN_KIND = Tags.SPAN_KIND_SERVER
  -* Tags.HTTP_METHOD
  -* Tags.HTTP_URL
  -* Tags.HTTP_STATUS
  -* Tags.ERROR (if true)
  -
  -Tags.SPAN_KIND MUST be specified at Span start time.
  +* `Tags.SPAN_KIND = Tags.SPAN_KIND_SERVER`
  +* `Tags.HTTP_METHOD`
  +* `Tags.HTTP_URL`
  +* `Tags.HTTP_STATUS`
  +* `Tags.ERROR` (if true)
  +
  +`Tags.SPAN_KIND` MUST be specified at Span start time.
   
   An https://github.com/opentracing/specification/blob/master/semantic_conventions.md[Tags.ERROR tag] SHOULD be added to a Span on failed operations for any server error (5xx) codes.
   If there is an exception object available the implementation SHOULD also add logs `event=error` and `error.object=<error object instance>` to the active span.
   
   ==== Span creation and injection for outbound requests
  -When a request is sent from a JAX-RS javax.ws.rs.client.Client, a new Span is created and its SpanContext is injected in the outbound request for propagation downstream. The new Span will be a child of the active Span if an active Span exists. The new Span will be finished when the outbound request is completed.
  +When a request is sent from a JAX-RS `javax.ws.rs.client.Client`, a new Span is created and its SpanContext is injected in the outbound request for propagation downstream. The new Span will be a child of the active Span if an active Span exists. The new Span will be finished when the outbound request is completed.
   
   ===== Client Span name
   The default operation name of the new Span for the outgoing request is
  
positive.code: This is particularly important in a microservices environment where a request typically flows through multiple services.
  To accomplish distributed tracing, each service must be instrumented to log messages with a correlation id that may have been propagated from an upstream service.
  A common companion to distributed trace logging is a service where the distributed trace records can be stored.
  See also http://opentracing.io/documentation/pages/supported-tracers.html[Examples on opentracing.io].
  The storage service for distributed trace records can provide features to view the cross service trace records associated with particular request flows.
  
  It will be useful for services written in the MicroProfile framework to be able to integrate well with a distributed trace system that is part of the larger microservices environment.
  
negative.code: }
  ----
  
  ==== Access to the configured tracer
  
  This proposal also specifies that the underlying OpenTracing Tracer object
  configured instance is available for developer use. The MicroProfile
  implementation will make the configured Tracer available with CDI injection.
  
  