<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to EYAML</title><link>https://sourceforge.net/p/hpg-projects/wiki/EYAML/</link><description>Recent changes to EYAML</description><atom:link href="https://sourceforge.net/p/hpg-projects/wiki/EYAML/feed" rel="self"/><language>en</language><lastBuildDate>Fri, 20 Jan 2023 12:15:26 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/hpg-projects/wiki/EYAML/feed" rel="self" type="application/rss+xml"/><item><title>EYAML modified by Hugh Greene</title><link>https://sourceforge.net/p/hpg-projects/wiki/EYAML/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;eYAML (ENIGMA's extended/easy YAML) is a simplified extension to&lt;br/&gt;
&lt;a class="" href="http://www.yaml.org/" rel="nofollow"&gt;YAML&lt;/a&gt;. It is a structured textual format for&lt;br/&gt;
properties, settings, extensions, dependencies, etc., similar in purpose&lt;br/&gt;
to XML. It is designed to keep the core elements of YAML while&lt;br/&gt;
eliminating the more complex elements, thus making parsing the format&lt;br/&gt;
much easier. YAML was chosen over XML for its simplicity,&lt;br/&gt;
human-readability, small filesize, ease of parsing, and general&lt;br/&gt;
prettiness compared to the ugly and redundant tags of XML.&lt;/p&gt;
&lt;p&gt;eYAML files must use the UTF-8 character set (this only affects files&lt;br/&gt;
with special characters).&lt;/p&gt;
&lt;h2 id="uses"&gt;Uses&lt;/h2&gt;
&lt;p&gt;ENIGMA makes use of the format to store various properties, settings,&lt;br/&gt;
configurations, module definitions, extensions, and dependencies.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a class="" href="../Compilers/" title="wikilink"&gt;Compilers/&lt;/a&gt; are defined by one eYAML file&lt;br/&gt;
    per platform compiler.&lt;/li&gt;
&lt;li&gt;&lt;a class="" href="/p/hpg-projects/wiki/About.ey/" title="wikilink"&gt;About.ey&lt;/a&gt; files define an available API or&lt;br/&gt;
    System.&lt;/li&gt;
&lt;li&gt;&lt;a class="" href="../Extensions/" title="wikilink"&gt;Extensions/&lt;/a&gt; are defined by them.&lt;/li&gt;
&lt;li&gt;&lt;a class="" href="/p/hpg-projects/wiki/EGM_format/" title="wikilink"&gt;EGM format&lt;/a&gt; uses it to format resource&lt;br/&gt;
    properties.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="similarity-to-properties"&gt;Similarity to Properties&lt;/h2&gt;
&lt;p&gt;On the simplest level, and the most common case seen throughout ENIGMA,&lt;br/&gt;
the 'structure' is minimal, yielding a basic list of `key: value`&lt;br/&gt;
pairs, not unlike a &lt;a class="" href="http://en.wikipedia.org/wiki/.properties" rel="nofollow"&gt;Properties&lt;br/&gt;
file&lt;/a&gt;. In fact, for such&lt;br/&gt;
cases, it is extremely common for a Properties parser to be used in&lt;br/&gt;
place of an eYAML parser, and the EGM format heavily relies on this&lt;br/&gt;
fact.&lt;/p&gt;
&lt;h2 id="specification"&gt;Specification&lt;/h2&gt;
&lt;p&gt;The specification for the format is unclear or informal because the&lt;br/&gt;
existing parsers do not follow any specifications attempted to be&lt;br/&gt;
written for them, and no specifications have been written to reflect the&lt;br/&gt;
parsers. Generally, they begin with the `%e-yaml` indicator on its own&lt;br/&gt;
line, optionally followed by a start of document `---` on its own&lt;br/&gt;
line. From there, the remainder of the document is broken into nodes&lt;br/&gt;
which are structured by indentation, which is usually denoted by the&lt;br/&gt;
space character, and not the tab character (the tab character is&lt;br/&gt;
forbidden in YAML for indentation). In this sense, the format resembles&lt;br/&gt;
that of the Python language.&lt;/p&gt;
&lt;h3 id="maps-and-lists"&gt;Maps and Lists&lt;/h3&gt;
&lt;p&gt;eYAML conserves the idea of Maps and Sequences from YAML, however the&lt;br/&gt;
simplified parsers tend to treat them interchangeably, meaning that a&lt;br/&gt;
bunch of children to a node would be interpreted depending on how the&lt;br/&gt;
program decides to use them. A map is denoted by a `key: value` pair,&lt;br/&gt;
while a sequence is usually denoted by either a hyphen preceding the&lt;br/&gt;
node `- node` or using brackets around the elements, delimited by&lt;br/&gt;
commas: `[1,2,3,4]`. Notice that a map allows the value to appear on&lt;br/&gt;
a newline with indentation exceeding the key, in which case the value&lt;br/&gt;
would be either its own mapping or sequence of nodes, each as a child to&lt;br/&gt;
the parent key.&lt;/p&gt;
&lt;h3 id="nodes-and-trees"&gt;Nodes and Trees&lt;/h3&gt;
&lt;p&gt;The first level of indentation (or no indentation) are root nodes. They&lt;br/&gt;
should all be the same type of node (e.g. all maps or all sequences -&lt;br/&gt;
not to be used interchangeably), but again, the 'type' essentially gets&lt;br/&gt;
erased by current parsers. Children nodes are on lines following a&lt;br/&gt;
parent node but preceding any siblings to the parent node, and are&lt;br/&gt;
indented more than the parent node. Children may themselves have&lt;br/&gt;
children, or may be 'leaf' nodes, creating a genuine tree structure, not&lt;br/&gt;
unlike a fully expanded graphical UI tree.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Hugh Greene</dc:creator><pubDate>Fri, 20 Jan 2023 12:15:26 -0000</pubDate><guid>https://sourceforge.net71ea7efc013e8c740719f91a95769da2b5c1e5d0</guid></item></channel></rss>