◇◆

<code> Code

A container element for technical content such as programming language code, pseudo-code, schemas, or a markup fragment.

Usage/Remarks

The <code> element may contain preformatted text, which may contain emphasis elements for syntax coloring, or it may contain an external link to a binary executable file.

Best Attribute Practice

The various semantic attributes should be used to name the type of code, the language, the intended platform(s), etc. Executable code should always be marked as such using the @executable attribute. The @specific-use attribute may also be used to describe the rationale or uses for a code sample.
Alternatives
When code is present in more than one form, the <code> element can be used inside an <alternatives> element. The various versions of the code can be syntax colored using the face markup from this Tag Set, syntax colored using processing instructions or other mechanisms from a syntax coloring program, plain ASCII for cut and paste, an executable version, etc.
MathML
The MathML elements to describe equations are not permitted within <code>. If equations are encountered within computer code, they can be tagged using the element <named-content> to preserve the fact that they were equations or the element <styled-content> to preserve the fact that they were set in a math font.
Related Elements
This element is similar to <preformat> in the preservation of whitespace, line-endings, and such formatting. The <code> element differs from <preformat> semantically; a <preformat> element may contain almost anything, for example, ASCII art, a man-machine dialog, error messages, 3 words on a line with space between them, or a poem. The <code> element is specifically for technical coding fragments, for example, computer programming language code; executable binary code; illustrative pseudo-code; an XSD, RNG or DTD schema fragment; a SQL or XQuery query; or a markup fragment that is part of an XML document instance.
Historical Note: Previous versions of this Tag Set have used the <preformat> element with an attribute @preformat-type="code" to express the semantic material that will hereafter be tagged as <code>.
Attributes
code-type
code-version
executable
language
language-version
orientation (default = portrait)
platforms
position (default = float)
specific-use
supplemental

Multi-lang Attributes

lang-focus
lang-focus-custom
lang-group
lang-source
lang-source-custom
lang-translate
lang-variant
lang-variant-custom

Base Attributes

id
xml:base
xml:lang

Miscellaneous non-JATS-specific Attributes

xml:space (fixed value = preserve)
Models and Context
May be contained in
<abstract>, <ack>, <alternatives>, <answer>, <app>, <app-group>, <bio>, <body>, <boxed-text>, <chem-struct>, <chem-struct-wrap>, <disp-formula>, <disp-quote>, <explanation>, <fig>, <floats-group>, <glossary>, <license-p>, <named-content>, <notes>, <option>, <p>, <question>, <question-preamble>, <ref-list>, <sec>, <see>, <see-also>, <styled-content>, <supplementary-material>, <table-wrap>, <td>, <term>, <th>, <trans-abstract>
Description
Any combination of:
Content Model
<!ELEMENT  code         (#PCDATA %code-elements;)*                   >
Expanded Content Model

(#PCDATA | email | ext-link | uri | bold | fixed-case | italic | monospace | overline | overline-start | overline-end | roman | sans-serif | sc | strike | underline | underline-start | underline-end | ruby | inline-graphic | inline-media | private-char | abbrev | index-term | index-term-range-end | milestone-end | milestone-start | named-content | styled-content | fn | target | xref | sub | sup)*

Tagged Samples
C++ code fragment 
...
<p>So, to make a simple button:
 <code   
   code-type="user-interface-control" 
   language="C++"
   language-version="11"
   xml:space="preserve" 
   orientation="portrait"
   position="anchor">
  #include &lt;conio.h>
  #include&lt;win_mous.cpp>
  // Needed for mouse and win functions#define
  OK (x>=170 &amp;&amp; x&lt;=210 &amp;&amp; y>=290 &amp;&amp; y&lt;=310)

  #define
  CANCEL (x>=280 &amp;&amp; x&lt;=330 &amp;&amp; y>=290 &amp;&amp; y&lt;=310)

  #define PUSHME (x>=170 &amp;&amp; x&lt;=330 &amp;&amp; y>=150 &amp;&amp; y&lt;=250)
 </code></p>
...
XML document fragment 
...
<p>An example XML WorkOrder element is shown as follows:
 <code 
   code-type="xml" 
   language-version="1.1"
   xml:space="preserve" 
   orientation="portrait"
   position="anchor" >
   ...
  &lt;WorkOrder ID="P7710">
   &lt;WorkItem name="Testing">
    &lt;Datum xsi:type="string" value="A123">
   &lt;/WorkItem>
  &lt;/WorkOrder>
   ...
 </code></p>
...
XSD Schema fragment 
...
<p>As of the release of this standard, the schema described 
 incorporates the following &ldquo;header&rdquo; information:
 <code 
   code-type="xml"
   language="xsd"
   language-version="1.1" 
   xml:space="preserve" 
   orientation="portrait"
   position="anchor" >
  &lt;xs:schema 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:c="urn:IEEE-1671:2008.01:Common"
    xmlns="urn:IEEE-1636.1:2008.01:TestResults"
    targetNamespace="urn:IEEE-1636.1:2008.01:TestResults"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified"
    version="2.01">
   &lt;xs:import namespace="urn:IEEE-1671:2008.01:Common"
     schemaLocation="Common.xsd"/>
  &lt;/xs:schema>
 </code></p>
...
DTD fragment 
...
<p>Trees, of course, are hardly a random choice for our
methodology. ... Hierarchical 
trees have been understood as a way of viewing document 
structures since before the earliest days of SGML 
development. Our initial tree structure was very simple:
 <code code-type="dtd">
  &lt;!ELEMENT  implications  (tree+) >
  &lt;!ELEMENT  tree          (root, branches) >
  &lt;!ELEMENT  root          (term, synonym?) >
  &lt;!ELEMENT  branches      (term | (term, synonym) | tree)* >
</code>
</p>
...
XSLT stylesheet fragment 
...
<p>Literal result elements are very convenient:
 <code code-type="xml" language="xslt">
  &lt;xsl:template match="sec/sec/title" priority="2">
    &lt;h2>
      &lt;xsl:apply-templates/>
    &lt;/h2>
  &lt;/xsl:template>
 </code>
</p>
...