You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -26,8 +26,7 @@ <h4><a id="c8.2.2.1"></a>// Clause 8.2.2.1 Line Terminators and White Space</h4>
26
26
<pre>WHITE_SPACE =
27
27
space | tab | form_feed | <ahref="#LINE_TERMINATOR_">LINE_TERMINATOR</a>
28
28
</pre>
29
-
<p>
30
-
// <strong>Notes:</strong></p>
29
+
<p>// <strong>Notes:</strong></p>
31
30
<ol>
32
31
<li>// 1. Notation text is divided up into lines separated by <em>line terminators</em>. A line terminator may be a single character (such as a line feed) or a sequence of characters (such as a carriage return/line feed combination). This specification does not require any specific encoding for a line terminator, but any encoding used must be consistent throughout any specific input text.</li>
33
32
<li>// 2. Any characters in text line that are not a part of the line terminator are referred to as <em>line text</em>.</li>
<li>// 1. The <code>single_quote</code> character is <code>'</code>. The name represented by an <code>UNRESTRICTED_NAME</code> shall consist of the characters <em>within</em> the single quotes, with escape characters resolved as described below. The surrounding single quote characters are <em>not</em> part of the represented name.</li>
99
97
<li>// 2. An <code>ESCAPE_SEQUENCE</code><em></em>is a sequence of two text characters starting with a backslash that actually denotes only a single character, except for the newline escape sequence, which represents however many characters is necessary to represent an end of line in a specific implementation (see also <ahref="#c8.2.2.1">8.2.2.1</a>). Table 4 shows the meaning of the allowed escape sequences. The <code>ESCAPE_SEQUENCES</code> in an <code>UNRESTRICTED_NAME</code> shall be replaced by the characters specified as their meanings in the actual represented name.</li>
<li>// 1. A <code>DECIMAL_VALUE</code> may specify a natural literal, or it may be part of the specification of a real literal (see <ahref="#c8.2.5.8.4">8.2.5.8.4</a>). Note that a <code>DECIMAL_VALUE</code> does not include a sign, because negating a literal is an operator in the KerML <code>Expression</code> syntax.</li>
114
111
<li>// 2. An <code>EXPONENTIAL_VALUE</code> may be used in the specification of a real literal (see <ahref="#c8.2.5.8.4">8.2.5.8.4</a>). Note that a decimal point and fractional part are not included in the lexical structure of an exponential value. They are handled as part of the syntax of real literals.</li>
body = <ahref="#REGULAR_COMMENT_">REGULAR_COMMENT</a>
245
239
</pre>
246
-
<p>
247
-
// <strong>Notes:</strong></p>
240
+
<p>// <strong>Notes:</strong></p>
248
241
<ol>
249
242
<li>// 1. The text of a lexical <code>REGULAR_COMMENT</code> or <code>PREFIX_COMMENT</code> shall be processed as follows before it is included as the body of a <code>Comment</code> or <code>Documentation</code>:
'language' language = <ahref="#STRING_VALUE_">STRING_VALUE</a>
269
262
body = <ahref="#REGULAR_COMMENT_">REGULAR_COMMENT</a>
270
263
</pre>
271
-
<p>
272
-
// <strong>Notes:</strong></p>
264
+
<p>// <strong>Notes:</strong></p>
273
265
<ol>
274
266
<li>// 1. The lexical text of a <code>REGULAR_COMMENT</code> shall be processed as specified in <ahref="#c8.2.3.3.2">8.2.3.3.2</a> for <code>Comments</code> before being included as the body of a <code>TextualRepresentation</code>.</li>
275
267
<li>// 2. See also 8.3.2.3.6 on the standard <code>language</code> names recognized for a <code>TextualRepresentation</code>.</li>
<li>// 1. A <em>root</em><code>Namespace</code> is a <code>Namespace</code> that has no <code>owningNamespace</code> (see 8.3.2.4). Every <code>Element</code> other than a root <code>Namespace</code> must be contained, directly or indirectly, within some root <code>Namespace</code>. Therefore, every valid KerML concrete syntax text can be parsed starting from the <code>RootNamespace</code> production.</li>
344
335
<li>// 2. <code>PrefixMetadataMember</code> is defined in the Kernel layer (see <ahref="#c8.2.5.12">8.2.5.12</a>).</li>
<li>// 1. The <code>importedMembership</code> of a <code>MembershipImport</code> is the single case in which the <code>Element</code> required from the resolution <code>[QualifiedName]</code> is the actual <code>Membership</code> identified by the <code>QualifedName</code>, <em>not</em> the <code>memberElement</code> of that <code>Membership</code> (see <ahref="#c8.2.3.5">8.2.3.5</a>).</li>
<li>// 1. <code>OperatorExpressions</code> provide a shorthand notation for <code>InvocationExpressions</code> that invoke a library <code>Function</code> represented as an <code>operator</code><em> symbol.</em> Table 5 shows the mapping from <code>operator</code> symbols to the <code>Functions</code> they represent from the Kernel Model Library (see Clause 9). An <code>OperatorExpression</code> contains subexpressions called its <em>operands</em> that generally correspond to the <code>argument</code><code>Expressions</code> of the <code>OperatorExpression</code>, except in the case of <code>operators</code> representing <em>control </em><code>Functions</code>, in which case the evaluation of certain operands is as determined by the <code>Function</code> (see 8.4.4.9 for details).</li>
1215
1203
<li>// 2. Though not directly expressed in the syntactic productions given above, in any <code>OperatorExpression</code> containing nested <code>OperatorExpressions</code>, the nested <code>OperatorExpressions</code> shall be implicitly grouped according to the <em>precedence</em> of the <code>operators</code> involved, as given in Table 6. <code>OperatorExpressions</code> with higher precedence <code>operators</code> shall be grouped more tightly than those with lower precedence <code>operators</code>. Further, all <code>BinaryOperators</code> other than exponentiation are left-associative (i.e, they group to the left), while the exponentiation operators (<code>^</code> and <code>**</code>) are right-associative (i.e., they group to the right).</li>
<li>// 1. Primary expressions provide additional shorthand notations for certain kinds of <code>InvocationExpressions</code>. For those cases in which the <code>InvocationExpression</code> is an <code>OperatorExpression</code>, its <code>operator</code> shall be resolved to the appropriate library function as given in Table 7. Note also that, for a <code>CollectionExpression</code> or <code>SelectExpression</code>, the abstract syntax constrains the <code>operator</code> to be <em><code>collect</code></em> and <em><code>select</code></em>, respectively, separately from the <code>.</code> and <code>.?</code> symbols used in their concrete syntax notation (see 8.3.4.8.2 and 8.3.4.8.18).</li>
1360
1347
<li>// 2. The grammar allows a bracket syntax <code>[</code>...<code>]</code>that parses to an invocation of the library <code>Function</code><code><em>Base</em></code><em><code>Functions::'['</code>,</em> as shown in Table 7. This notation is available for use with domain-specific library models that given a concrete definition to the abstract base <code>'['</code><code>Function</code>, but no default definition is provided in the Kernel Functions Library. If no domain-specific definition is available, a tool should give a warning if this operator is used.</li>
<li>// 1. To ensure that an <code>FlowFeature</code> passes the <code>validateRedefinitionDirectionConformance</code> constraint (see 8.3.3.3.8), its <code>direction</code> must be set to the direction of its <code>redefinedFeature</code>, relative to its owning <code>FlowEnd</code>, that is, the result of the following OCL expression: <code>owningType.directionOf(ownedRedefinition->at(1).redefinedFeature)</code></li>
// Generated by bnf_grammar_extractor at: 2025-12-02T13:27:26Z
2
+
// Generated by bnf_grammar_processor at: 2025-12-04T19:31:35Z
4
3
5
4
6
5
// Part 1 - Kernel Modeling Language (KerML)
@@ -212,7 +211,7 @@ Documentation =
212
211
// • Strip initial white space other than line terminators.
213
212
// • Then, if the first remaining character is "*", remove it.
214
213
// • Then, if the first remaining character is now a space, remove it.
215
-
// 2. The body text of a Comment can include markup information (such as HTML), and a conforming tool may display such text as rendered according to the markup. However, marked up "rich text" for a Comment written using the KerML textual concrete syntax shall be stored in the Comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules above.
214
+
// 2. The body text of a Comment can include markup information (such as HTML), and a conforming tool may display such text as rendered according to the markup. However, marked up "rich text" for a Comment written using the KerML textual concrete syntax shall be stored in the Comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules above.
0 commit comments