◇◆
<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.
Attributes
orientation (default = portrait)
position (default = float)
Multi-lang Attributes
Miscellaneous non-JATS-specific Attributes
xml:space (fixed value = preserve)
Models and Context
May be contained in
<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>
Description
Any combination of:
- Text, numbers, or special characters
- Linking Elements
- Emphasis Elements
- Inline Display Elements
- Other Inline Elements
- Internal Linking Elements
- Baseline Change Elements
Content Model
<!ELEMENT code (#PCDATA %code-elements;)* >
Expanded Content Model
(#PCDATA | email | ext-link | uri | bold | fixed-case | italic | monospace | overline | roman | sans-serif | sc | strike | underline | 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 <conio.h>
#include<win_mous.cpp>
// Needed for mouse and win functions#define
OK (x>=170 && x<=210 && y>=290 && y<=310)
#define
CANCEL (x>=280 && x<=330 && y>=290 && y<=310)
#define PUSHME (x>=170 && x<=330 && y>=150 && y<=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" >
...
<WorkOrder ID="P7710">
<WorkItem name="Testing">
<Datum xsi:type="string" value="A123">
</WorkItem>
</WorkOrder>
...
</code></p>
...
XSD Schema fragment
...
<p>As of the release of this standard, the schema described
incorporates the following “header” information:
<code
code-type="xml"
language="xsd"
language-version="1.1"
xml:space="preserve"
orientation="portrait"
position="anchor" >
<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">
<xs:import namespace="urn:IEEE-1671:2008.01:Common"
schemaLocation="Common.xsd"/>
</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">
<!ELEMENT implications (tree+) >
<!ELEMENT tree (root, branches) >
<!ELEMENT root (term, synonym?) >
<!ELEMENT branches (term | (term, synonym) | tree)* >
</code>
</p>
...
XSLT stylesheet fragment
...
<p>Literal result elements are very convenient:
<code code-type="xml" language="xslt">
<xsl:template match="sec/sec/title" priority="2">
<h2>
<xsl:apply-templates/>
</h2>
</xsl:template>
</code>
</p>
...