anchor.diff:  
   . Macro name, e.g. `issue`
   . One colon, i.e. `:`.
  -  This is what distinguishes it from a block macro even if being alone in a paragraph.
  -. A target, e.g. `333`
  -. Attributes, e.g. `[repo=asciidoctor/asciidoctorj]`.
  +  This is what distinguishes it from a block macro even if it is alone in a paragraph.
  +. An optional target, e.g. `333`
  +. Optional attributes, e.g. `[repo=asciidoctor/asciidoctorj]`.
   
   Our example inline macro processor should create a link to the issue #333 of the repository `asciidoctor/asciidoctorj` on GitHub.
   If the attribute `repo` in the macro is empty it should fall back to the document attribute `repo`.
  
positive.code: 
  Now that you have learned about the AST structure you can go into the details of the extensions.
  
  === Block Macro Processors
  
  A block macro is a block having a content like this: `gist::mygithubaccount/8810011364687d7bec2c[]`.
  
negative.code: Asciidoctor provides seven types of extension points.
  Each extension point has an abstract class in Java that maps to the extension API in Ruby.
  
  // #31
  
  [cols="1m,2m,2"]
  .AsciidoctorJ extension APIs
  |===
  |Name |Class |Description
  
  |<<includeprocessor,Include processor>>
  |org.asciidoctor.extension.IncludeProcessor
  |intercepts `include::[]` lines
  
  |<<preprocessor,Preprocessor>>
  |org.asciidoctor.extension.Preprocessor
  |Allows you to modify the asciidoc text before parsing
  
  |<<blockmacroprocessor,Block macro processor>>
  |org.asciidoctor.extension.BlockMacroProcessor
  |Processes block macros like `bibliography::[]`
  
  |<<blockprocessor,Block processor>>
  |org.asciidoctor.extension.BlockProcessor
  a|Processes an arbitary block based on it's style such as 
  
   [prohibited]
   --
   Do not enter
   --
  
  |<<treeprocessor,Treeprocessor>>
  |org.asciidoctor.extension.Treeprocessor
  |Modify the AST after parsing
  
  |<<inlineprocessor,Inline macro processor>>
  |org.asciidoctor.extension.InlineMacroProcessor
  |Processes inline macros like `btn:[]`
  
  |<<postprocessor,Postprocessor>>
  |org.asciidoctor.extension.Postprocessor
  |Modifies the backend-specific output document
  
  |<<docinfoprocessor,DocinfoProcessor>>
  |org.asciidoctor.extension.DocinfoProcessor
  |Insert content into the `header` element (html) or `docinfo` element (docbook)
  |===
  
  [NOTE]
  --
  .Order of execution
  The extension types are called during the conversion process in the order shown in the table.
  Within each type:
  
  * Include processors are called in an arbitrary and changeable order. 
  The first processor to accept the include line is the only one that is used.
  
  * Block macro, inline macro, and block processors are called in the order that they appear in the document.
  
  * Prepocessors, Treeprocessors, Postprocessors and DocinfoProcessors are called in an arbitrary and changeable order.
  --
  
  To create an extension two things are required:
  
  