Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

On this page

In this section

Example 1: Appendices

All appendix content must start with a paragraph styled as:

  • an appendix head,

  • appendix number,

  • or with a figure or table that has:

    • “Appendix” in the label (e.g., “Appendix 1”)

    • an uppercase letter preceding the number (e.g., “Table A1”).

Appendices require some distinct heading and paragraph styles. It is important that the correct appendix styles be used to avoid parsing errors or incorrect XML.

The following example shows the proper styling of appendices.

The regular P2–P6 paragraph styles from the Body tab can be used in an appendix, but the specific Appendix Head 1–3 and Appendix Text must be used as shown.

Word Sample

Screenshot in Draft View of an appendix example. The paragraph styles visible from top down are Appendix_Title, Appendix_Head_1, P2, Appendix_Head_1, P2, P3, Appendix_Text

XML Sample

<back>
<app-group>
<app id="sec_A"><label>APPENDIX A</label><title>ADDITIONAL INFORMATION ON TEST PROCEDURES</title>
<sec id="sec_A.1">
<label>A.1</label><title>SCOPE</title>
<sec id="sec_A.1.1"><label>A.1.1</label><title>Scope</title>
<p>This appendix is a mandatory part of this specification. The information contained herein is intended for compliance. This appendix is to provide additional information to the user of this specification in performing the voltage standing wave ratio, RF leakage, and insertion loss tests.</p>
</sec>
</sec>
<sec id="sec_A.2">
<label>A.2</label><title>TEST TYPES</title>
<sec id="sec_A.2.1"><label>A.2.1</label>
<p>Voltage standing wave ratio (see <underline>4.6.11</underline>).</p>
<sec id="sec_A.2.1.1"><label>A.2.1.1</label><title>Test connector</title>
<p>The standard test-connector interface shall be in accordance with <std><underline><std-ref type="undated">MIL-STD-348</std-ref></underline></std>. The standard test connector impedance shall be 50 ± 0.5 ohms.</p>
</sec>
</sec>
</sec>
<sec id="sec_A.3">
<label>A.3</label><title>MEASUREMENTS</title>
<sec id="sec_A.3.1"><label>A.3.1</label>
<p>RF leakage (see <underline>4.6.23</underline>).</p>
<sec id="sec_A.3.1.1"><label>A.3.1.1</label><title>Measurement technique</title>
<p>The measurement of the leakage from connectors is performed by collecting the leakage energy in a coaxial system surrounding the leakage source. An outline of the instrumentation is shown on figure 7.</p>
<p>For direct leakage measurements the adjustable short circuit serves several purposes.</p>
<p>The short-circuit position is adjusted to assure that an adequately low impedance appears behind the equivalent leakage generator. A matched termination can be substituted, but the resulting 6-dB loss cannot be tolerated in some cases. In addition, if the leakage source is directional, as it indeed is for connectors with multiple leakage, it is possible for the leakage to be directed to this termination at some frequencies and not collected by the detector. For surface transfer-impedance measurements on connectors with leakage from more than one point in the connector, however, a matched termination is desirable in order to simplify the transformation of the measured data to absolute transfer impedance data. This is not needed to make relative comparisons in this test.</p>
</sec>
</sec>
</sec>
</app>
</app-group>
</back>

Example 2: References/Bibliography

The following example shows a properly styled document reference list.

Bibliography items may or may not be cited in the document body; references typically are cited.

Bibliography and reference items are distinct from normative references, which are indispensable to the application of the standard.

Word Sample

Screenshot in Draft View of a reference section. It has already been fully color-coded with tags and character styles. The Reference Head is styled as BiblioHead, and all the references are styled as BiblioEntry

XML Sample

eXtyles leverages the character-styling of the reference list (applied during Standards Reference Processing) to add granular tagging to the reference entries (e.g. <surname>, <given-names>, and <year>).

<back>
<ref-list>
<title>References</title>
<ref id="ref_1"><label>1</label><mixed-citation publication-type="confproc"><string-name><surname>Acar</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Backes</surname> <given-names>M</given-names></string-name>, <string-name><surname>Fahl</surname> <given-names>S</given-names></string-name>, <string-name><surname>Kim</surname> <given-names>D</given-names></string-name>, <string-name><surname>Mazurek</surname> <given-names>ML</given-names></string-name>, <string-name><surname>Stransky</surname> <given-names>C</given-names></string-name> (<year>2016</year>) <article-title>You get where you’re looking for: The impact of information sources on code security.</article-title> <source>Proceedings of the 37th IEEE Symposium on Security and Privacy</source>, pp <fpage>289</fpage>–<lpage>305</lpage>.</mixed-citation></ref>
<ref id="ref_2"><label>2</label><mixed-citation publication-type="confproc"><string-name><surname>Duong</surname> <given-names>T</given-names></string-name>, <string-name><surname>Rizzo</surname> <given-names>J</given-names></string-name> (<year>2011</year>) <article-title>Cryptography in the web: The case of cryptographic design flaws in ASP.NET.</article-title> <source>Proceedings of the 31st IEEE Symposium on Security and Privacy</source>, pp <fpage>481</fpage>–<lpage>489</lpage>.</mixed-citation></ref>
<ref id="ref_3"><label>3</label><mixed-citation publication-type="confproc"><string-name><surname>Egele</surname> <given-names>M</given-names></string-name>, <string-name><surname>Brumley</surname> <given-names>D</given-names></string-name>, <string-name><surname>Fratantonio</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Kruegel</surname> <given-names>C</given-names></string-name> (<year>2013</year>) <article-title>An empirical study of cryptographic misuse in Android applications.</article-title> <source>Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security (CCS ’13)</source>, pp <fpage>73</fpage>–<lpage>84</lpage>.</mixed-citation></ref>
<ref id="ref_4"><label>4</label><mixed-citation publication-type="confproc"><string-name><surname>Fahl</surname> <given-names>S</given-names></string-name>, <string-name><surname>Harbach</surname> <given-names>M</given-names></string-name>, <string-name><surname>Muders</surname> <given-names>T</given-names></string-name>, <string-name><surname>Baumgartner</surname> <given-names>L</given-names></string-name>, <string-name><surname>Freisleben</surname> <given-names>B</given-names></string-name>, <string-name><surname>Smith</surname>, <given-names>M</given-names></string-name> (<year>2012</year>) <article-title>Why Eve and Mallory love Android: An analysis of Android SSL (in)security.</article-title> <source>Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS ’12)</source>, pp <fpage>50</fpage>–<lpage>61</lpage>.</mixed-citation></ref>
<ref id="ref_5"><label>5</label><mixed-citation publication-type="confproc"><string-name><surname>Nadi</surname> <given-names>S</given-names></string-name>, <string-name><surname>Kruger</surname> <given-names>S</given-names></string-name>, <string-name><surname>Mezini</surname> <given-names>M</given-names></string-name>, <string-name><surname>Bodden</surname> <given-names>E</given-names></string-name> (<year>2016</year>) <article-title>Jumping through hoops: Why do Java developers struggle with cryptography APIs?</article-title> <source>Proceedings of the 38th International Conference on Software Engineering (ICSE ’16)</source>, pp <fpage>935</fpage>–<lpage>946</lpage>.</mixed-citation></ref>
<ref id="ref_6"><label>6</label><mixed-citation publication-type="confproc"><string-name><surname>Haney</surname> <given-names>JM</given-names></string-name>, <string-name><surname>Theofanos</surname> <given-names>MF</given-names></string-name>, <string-name><surname>Acar</surname> <given-names>Y</given-names></string-name>, <string-name><surname>Prettyman</surname> <given-names>SS</given-names></string-name> (<year>2018</year>) “<article-title>We make it a big deal in the company</article-title>”: Security mindsets in organizations that develop cryptographic products. <source>Proceedings of the 14<sup>th</sup> Symposium on Usable Privacy and Security</source>, pp <fpage>357</fpage>-<lpage>373</lpage>.</mixed-citation></ref>
<ref id="ref_7"><label>7</label><mixed-citation publication-type="web"><collab>National Institute of Standards and Technology</collab> (<year>2001</year>) <source>Security requirements for cryptographic modules</source>, Federal Information Processing Standard Publication 140-2, <ext-link ext-link-type="uri" xlink:href="http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf">http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf</ext-link> <comment>[accessed 8/1/2018]</comment></mixed-citation></ref>
</ref-list>
</back>

  • No labels

Copyright © 2022 Atypon Systems, LLC. All Rights Reserved.