Dropped normative statement from "Basic" and "Advanced" sections.
authorFrançois Daoust <francois@joshfire.com>
Mon, 05 Nov 2012 11:03:51 +0100
changeset 950 2c5820b6b4b7
parent 949 6617339f9619
child 951 c12d395206db
Dropped normative statement from "Basic" and "Advanced" sections.

Grammar completed as necessary when the normative statements were
not captured yet (e.g. the constraint on circular dependencies
for terms definitions in a context).

Also: IRI definition modified to say that an IRI may either be
represented as an absolute IRI or a relative IRI. "terms" and
"compact IRIs" were also in the list previously, but they generate
IRIs through expansion, and the grammar makes the distinction
when it says that a value can be an IRI, a compact IRI or a term.

Normative statements on JSON-LD processors still appear in the
doc, but should probably be removed.

Also note the "Referencing Contexts from JSON Documents" section
retains its normative wording.

I also updated plural references to terms to include the "s" to
ensure the whole world gets turned into a link.
spec/latest/json-ld-syntax/index.html
--- a/spec/latest/json-ld-syntax/index.html	Mon Nov 05 09:15:09 2012 +0100
+++ b/spec/latest/json-ld-syntax/index.html	Mon Nov 05 11:03:51 2012 +0100
@@ -332,10 +332,10 @@
   it introduces:</p>
 
 <ul>
-  <li>a universal identifier mechanism for <tref>JSON object</tref>s via the
-    use of <tref>IRI</tref>s,</li>
+  <li>a universal identifier mechanism for <tref title="JSON object">JSON objects</tref> via the
+    use of <tref title="IRI">IRIs</tref>,</li>
   <li>a way to disambiguate the keys used between multiple JSON documents
-    by mapping them to <tref>IRI</tref>s via a <tref>context</tref>,</li>
+    by mapping them to <tref title="IRI">IRIs</tref> via a <tref>context</tref>,</li>
   <li>a mechanism in which a value in a <tref>JSON object</tref> may refer
     to a <tref>JSON object</tref> on a different site on the Web,</li>
   <li>the ability to express the language associated with a <tref>string</tref></li>
@@ -479,7 +479,7 @@
 <p>There are a number of best practices that can ensure that developers
   will generate good <tref>Linked Data</tref> for the Web. JSON-LD
   formalizes those techniques by providing a mechanism to map JSON data,
-  i.e., keys and values, to <tref>IRI</tref>s. This does not mean
+  i.e., keys and values, to <tref title="IRI">IRIs</tref>. This does not mean
   that JSON-LD requires every key or value to be an IRI, but rather ensures that
   keys and values can be mapped to IRIs if the developer desires to transform
   their data into <tref>Linked Data</tref>.</p>
@@ -542,7 +542,7 @@
 <dl>
 <dt><code>@context</code></dt>
 <dd>Used to define the short-hand names that are used throughout a JSON-LD
-  document. These short-hand names are called <tref>term</tref>s and help
+  document. These short-hand names are called <tref title="term">terms</tref> and help
   developers to express specific identifiers in a compact manner. The
   <code>@context</code> keyword is described in detail in the section titled
   <a href="#the-context"></a>.</dd>
@@ -619,15 +619,12 @@
   ensure that these terms are unambiguous. For example, the term <code>name</code> may
   map directly to the IRI <code>http://xmlns.com/foaf/0.1/name</code>. This allows JSON-LD documents to be constructed
   using the common JSON practice of simple key-value pairs while ensuring that the data is useful outside of the
-  page, API or database in which it resides. The value of a term mapping
-  MUST be either; 1) a simple string with the lexical form of an <tref>absolute IRI</tref> or
-  2) <tref>compact IRI</tref>, or 3) an <tref>JSON object</tref> containing an
-  <code>@id</code>, <code>@type</code>, <code>@language</code>, or <code>@container</code> keyword
-  (all other keywords are ignored by a JSON-LD processor).
+  page, API or database in which it resides.
 </p>
 
-<p>These Linked Data <tref>term</tref>s are typically collected in a
-context document that would look something like this:</p>
+<p>In a JSON-LD document, the mapping between <tref title="term">terms</tref> and
+  <tref title="IRI">IRIs</tref> is typically collected in a <tref>context definition</tref>
+  that would look something like this:</p>
 
 <pre class="example" data-transform="updateExample"
      title="Context definition">
@@ -690,17 +687,20 @@
 expressing the same concept. This allows both developers to re-use each others'
 data without having to agree to how their data will interoperate on a
 site-by-site basis. Contexts may also contain type information
-for certain <tref>term</tref>s as well as other processing instructions for
+for certain <tref title="term">terms</tref> as well as other processing instructions for
 the JSON-LD processor.</p>
 
-<p>External JSON-LD context documents MAY contain extra information
+<p>External JSON-LD context documents may contain extra information
 located outside of the <code>@context</code> key, such as documentation about the
 <tref title="term">terms</tref> declared in the document. When importing a
-<code>@context</code> value from an external JSON-LD context document, any extra
-information contained outside of the <code>@context</code> value MUST be discarded.</p>
-
-<p>Contexts MAY be specified in-line. This ensures that JSON-LD documents
-can be processed when a JSON-LD processor does not have access to the Web.</p>
+<code>@context</code> value from an external JSON-LD context document,
+<tref title="JSON-LD processor">JSON-LD processors</tref> MUST discard
+information contained outside of the <code>@context</code> value.</p>
+
+<p>Contexts may also be specified in-line. This ensures that
+  <tref title="JSON-LD document">JSON-LD documents</tref>
+  can be processed when a <tref>JSON-LD processor</tref> does not have access to
+  the Web.</p>
 
 <pre class="example" data-transform="updateExample"
      title="In-line context definition">
@@ -727,12 +727,12 @@
 -->
 </pre>
 
-<p>Contexts MAY be used at any time a <tref>node definition</tref> is defined.
-  A <tref>node definition</tref> MAY specify multiple contexts, using an
-  <tref>array</tref>, which is processed in order. This is useful
-  when an author would like to use an existing context and add
-  application-specific terms to the existing context. Duplicate context
-  <tref>term</tref>s MUST be overridden using a last-defined-overrides
+<p>Contexts may be used at any time a <tref>node definition</tref> is defined.
+  A <tref>node definition</tref> may specify multiple contexts, using an
+  <tref>array</tref>, which <tref title="JSON-LD processor">JSON-LD processors</tref>
+  process in order. This is useful when an author would like to use an existing context
+  and add application-specific terms to the existing context. Duplicate context
+  <tref title="term">terms</tref> are overridden using a last-defined-overrides
   mechanism.</p>
 
 <pre class="example" data-transform="updateExample"
@@ -763,13 +763,13 @@
   legacy applications that depend on the specific structure of the
   <tref>JSON object</tref>. If a <tref>term</tref> is re-defined within a
   context, all previous rules associated with the previous definition are
-  removed. A <tref>term</tref> defined in a previous context MUST be removed,
-  if it is re-defined to <code>null</code>.</p>
+  removed. A <tref>term</tref> defined in a previous context MUST be removed
+  by the <tref>JSON-LD processor</tref> if it is re-defined to <code>null</code>.</p>
 
 <p>The set of contexts defined within a specific <tref>node definition</tref> are
-  referred to as <tdef>local context</tdef>s. Setting the context to <code>null</code>
+  referred to as <tdef title="local context">local contexts</tdef>. Setting the context to <code>null</code>
   effectively resets the <tref>active context</tref> to an empty context. The
-  <tdef>active context</tdef> refers to the accumulation of <tref>local context</tref>s
+  <tdef>active context</tdef> refers to the accumulation of <tref title="local context">local contexts</tref>
   that are in scope at a specific point within the document. The following example
   specifies an external context and then layers a local context on top of the external
   context:</p>
@@ -802,7 +802,7 @@
 <section>
 <h2>From JSON to JSON-LD</h2>
 
-<p>If a set of <tref>term</tref>s such as, <strong>name</strong>,
+<p>If a set of <tref title="term">terms</tref> such as, <strong>name</strong>,
 <strong>homepage</strong>, and <strong>depiction</strong>,
 are defined in a <tref>context</tref>, and that context is used to resolve the
 names in <tref title="JSON object">JSON objects</tref>, machines are able to automatically expand the terms to
@@ -832,7 +832,7 @@
   <tref>node definition</tref>. <tref title="node definition">Node definitions</tref>
   do not require an <code>@id</code>.
   <tref title="node definition">Node definitions</tref> that do not
-  contain an <code>@id</code> are known as an <tref title="unlabeled node">unlabeled nodes</tref>.</p>
+  contain an <code>@id</code> are known as <tref title="unlabeled node">unlabeled nodes</tref>.</p>
 
 </section>
 
@@ -841,8 +841,8 @@
 
 <p><tdef title="IRI"><abbr title="Internationalized Resource Identifier">IRIs</abbr></tdef>
   (Internationalized Resource Identifiers are fundamental to <tref>Linked Data</tref> as
-  that is how most <tref title="node">nodes</tref>s and <tref title="property">properties</tref>
-  are identified. <tref>IRI</tref>s can be expressed in a variety of different ways in JSON-LD:</p>
+  that is how most <tref title="node">nodes</tref> and <tref title="property">properties</tref>
+  are identified. <tref title="IRI">IRIs</tref> can be expressed in a variety of different ways in JSON-LD:</p>
 
 <ol>
   <li>Except within a <tref>context</tref> definition, <tref title="term">terms</tref> in the
@@ -856,12 +856,11 @@
     are <tref>coercion</tref> rules in effect that identify the value as an <code>@id</code>.</li>
 </ol>
 
-<p>IRIs may be represented as an <tref>absolute IRI</tref>, a <tref>relative IRI</tref>,
-  a <tref>compact IRI</tref>, or a <tref>term</tref>.</p>
+<p>IRIs may be represented as an <tref>absolute IRI</tref> or a <tref>relative IRI</tref>.</p>
 
 <p>An <tdef>absolute IRI</tdef> is defined in [[!RFC3987]] containing a <em>scheme</em> along with
   <em>path</em> and optional <em>query</em> and <em>fragment</em> segments. A <tdef>relative IRI</tdef> is an IRI
-  that is relative to some other <tref>absolute IRI</tref>. In JSON-LD all <tref>relative IRI</tref>s are resolved relative to the
+  that is relative to some other <tref>absolute IRI</tref>. In JSON-LD all <tref title="relative IRI">relative IRIs</tref> are resolved relative to the
   <tdef>base IRI</tdef> associated with the document (typically, the directory that contains the document or the document itself).</p>
 
 <p>IRIs can be expressed directly in the key position like so:</p>
@@ -901,7 +900,7 @@
 -->
 </pre>
 
-<p><tref>Term</tref>s are case sensitive, and MUST be matched using a case-sensitive comparison.</p>
+<p><tref title="term">Terms</tref> are case sensitive, and MUST be matched by a <tref>JSON-LD processor</tref> using a case-sensitive comparison.</p>
 
 <p>JSON keys that do not expand to an absolute IRI are ignored, or removed
 in some cases, by the [[JSON-LD-API]]. However, JSON keys that do not include
@@ -909,7 +908,7 @@
 in JSON-LD documents - the keys just don't have any machine-readable,
 semantic meaning.</p>
 
-<p><tref>Prefix</tref>es are expanded when the form of the value is a
+<p><tref title="prefix">Prefixes</tref> are expanded when the form of the value is a
   <tref>compact IRI</tref> represented as a <code>prefix:suffix</code>
   combination, and the prefix matches a <tref>term</tref> defined within the
   <tref>active context</tref>:</p>
@@ -935,8 +934,7 @@
 <p>It is often common that all types and properties come from the same vocabulary. JSON-LD's
   <code>@vocab</code> keyword allows to set a common prefix to be used for all properties and types
   that neither match a <tref>term</tref> nor a <tref>compact IRI</tref> or an <tref>absolute IRI</tref>
-  (i.e., do not contain a colon). The <code>@vocab</code> mapping MUST have a value of a simple string with the
-  lexical form of an absolute IRI.</p>
+  (i.e., do not contain a colon).</p>
 
 <pre class="example" data-transform="updateExample"
      title="Using a common vocabulary prefix">
@@ -969,7 +967,7 @@
   <code>@id</code> key is used to identify that <tref>node</tref> using an
   <tref>IRI</tref>. When the object has only the <code>@id</code>, it
   is called a <tref>node reference</tref>.
-  This facility MAY also be used to link to another
+  This facility may also be used to link to another
   <tref>node definition</tref> using a mechanism called
   <tref>embedding</tref>, which is covered in the section titled
   <a href="#embedding"></a>.</p>
@@ -1009,7 +1007,7 @@
 <h2>Node Identifiers</h2>
 
 <p>To be able to externally reference nodes in a graph, it is important that each node has
-  an unambiguous identifier. <tref>IRI</tref>s are a fundamental concept of
+  an unambiguous identifier. <tref title="IRI">IRIs</tref> are a fundamental concept of
   <tref>Linked Data</tref>, and nodes should have a de-referencable
   identifier used to name and locate them. For nodes to be truly linked,
   de-referencing the identifier should result in a representation of that node
@@ -1051,8 +1049,7 @@
   <tref>node definition</tref>. <tref title="node definition">Node definitions</tref>
   do not require an <code>@id</code>. A <tref>node definition</tref>
   that does not contain an <code>@id</code> property defines properties of an
-  <tref>unlabeled node</tref>. <tref title="node definition">Node definitions</tref> MAY
-  be spread among different parts of a document or even between different documents.</p>
+  <tref>unlabeled node</tref>.</p>
 
 </section>
 
@@ -1060,8 +1057,8 @@
 <h2>Specifying the Type</h2>
 
 <p>The type of a particular node can be specified using the <code>@type</code>
-  <tref>keyword</tref>. To be considered <tref>Linked Data</tref>, types MUST
-  be uniquely identified by an <tref>IRI</tref>.</p>
+  <tref>keyword</tref>. In <tref>Linked Data</tref>, types are uniquely
+  identified with an <tref>IRI</tref>.</p>
 
 <pre class="example" data-transform="updateExample"
      title="Specifying the type for a node">
@@ -1118,11 +1115,10 @@
 </pre>
 
 <p>The example above would associate the <code>ja</code> language
-  code with the two <tref>string</tref>s <em>花澄</em> and <em>科学者</em>.
-  Languages MUST be well-formed language tags according to [[!BCP47]].</p>
-
-<p>It is possible to override the default language by using the expanded
-form of a value:</p>
+  code with the two <tref title="string">strings</tref> <em>花澄</em> and <em>科学者</em>.
+  Languages codes are defined in [[!BCP47]].</p>
+
+<p>It is possible to override the default language by using an <tref>expanded value</tref>:</p>
 
 <pre class="example" data-transform="updateExample"
      title="Expanded value with language">
@@ -1143,7 +1139,7 @@
 
 <p>It is also possible to override the default language or specify a plain
 value by omitting the <code>@language</code> tag or setting it to
-<code>null</code> when expressing the expanded value:</p>
+<code>null</code> when expressing the <tref>expanded value</tref>:</p>
 
 <pre class="example" data-transform="updateExample"
      title="Expanded value to remove language">
@@ -1165,10 +1161,10 @@
 -->
 </pre>
 
-<p>Please note that language associations MUST only be applied to plain
-  literal <tref>string</tref>s. That is, <tref>typed value</tref>s
-  or values that are subject to <a href="#type-coercion"></a>
-  won't be language tagged.</p>
+<p>Please note that language associations can only be applied to plain
+  literal <tref title="string">strings</tref>. That is,
+  <tref title="typed value">typed values</tref> or values that are subject
+  to <a href="#type-coercion"></a> cannot be language tagged.</p>
 
 <p>To clear the default language for a subtree, <code>@language</code> can
 be set to <code>null</code> in a <tref>local context</tref> as follows:</p>
@@ -1193,7 +1189,7 @@
 </pre>
 
 <p class="note">JSON-LD allows one to associate language information with
-  <tref>term</tref>s. See <a href="#expanded-term-definition"></a> for
+  <tref title="term">terms</tref>. See <a href="#expanded-term-definition"></a> for
   more details.</p>
 
 </section>
@@ -1201,16 +1197,16 @@
 <section>
   <h2>JSON-LD Syntax</h2>
 
-  <p>A JSON-LD document is first, and foremost, a JSON document
+  <p>A <tref>JSON-LD document</tref> is first, and foremost, a JSON document
     (as defined in [[!RFC4627]]), and any syntactically correct JSON document
-    MUST be processed by a conforming JSON-LD processor. However, JSON-LD
+    MUST be processed by a conforming <tref>JSON-LD processor</tref>. However, JSON-LD
     describes a specific syntax to use for expressing Linked Data. This
     includes the use of specific keywords, as identified in <a
     href="#syntax-tokens-and-keywords"></a> for
     expressing <a title="node definition">node definitions</a>, values,
     and the <a>context</a>. See <a
     href="#json-ld-grammar"></a> for authoring
-    guidelines and a BNF description of JSON-LD.</p>
+    guidelines.</p>
 
 </section>
 </section>
@@ -1228,14 +1224,14 @@
 <section>
   <h2>Compact IRIs</h2>
   <p>
-    <tref>Term</tref>s in <tref>Linked Data</tref> documents may draw from
+    <tref title="term">Terms</tref> in <tref>Linked Data</tref> documents may draw from
     a number of different <tref title="vocabulary">vocabularies</tref>.
     At times, declaring every single <tref>term</tref> that a document uses can require the
     developer to declare tens, if not hundreds of potential
-    <tref>vocabulary</tref> <tref>term</tref>s that are used across an
+    <tref>vocabulary</tref> <tref title="term">terms</tref> that are used across an
     application. This is a concern for at least two reasons: the
     first is the cognitive load on the developer of remembering all of the
-    <tref>term</tref>s, and the second is the serialized size of the
+    <tref title="term">terms</tref>, and the second is the serialized size of the
     <tref>context</tref> if it is specified inline. In order to address these issues,
     the concept of a <tref>compact IRI</tref> is introduced.</p>
   <p>
@@ -1255,7 +1251,7 @@
     Instead of having to remember and type out the entire IRI, the developer
     can instead use the prefix in their JSON-LD markup.
   </p>
-  <p>Terms are interpreted as <tref>compact IRI</tref>s if they contain at least one
+  <p>Terms are interpreted as <tref title="compact IRI">compact IRIs</tref> if they contain at least one
     colon and the first colon is not followed by two slashes (<code>//</code>, as in
     <code>http://example.com</code>). To generate the full <tref>IRI</tref>,
     the value is first split into a <em>prefix</em> and <em>suffix</em> at the first
@@ -1564,7 +1560,7 @@
 
 <p>
 In order to use an external context with an ordinary JSON document, an author
-MUST specify an <tref>IRI</tref> to a valid JSON-LD document in an HTTP Link
+MUST specify an <tref>IRI</tref> to a valid <tref>JSON-LD document</tref> in an HTTP Link
 Header [[!RFC5988]] using the <code>describedby</code> link relation.
 
 The referenced document MUST have a top-level <tref>node definition</tref>. The
@@ -1601,7 +1597,8 @@
 -->
 </pre>
 
-<p>Please note that JSON-LD documents served with the <code>application/ld+json</code>
+<p>Please note that <tref title="JSON-LD document">JSON-LD documents</tref>
+  served with the <code>application/ld+json</code>
   media type MUST have all context information, including references to external
   contexts, within the body of the document. Contexts linked via a
   <code>describedby</code> HTTP Link Header MUST be ignored for such documents.</p>
@@ -1610,16 +1607,16 @@
 <section>
 <h3>Expanded Term Definition</h3>
 
-<p>Within a <tref>context</tref> definition, <tref>term</tref>s MAY be
-   defined using an expanded notation to allow for additional information
+<p>Within a <tref>context</tref> definition, <tref title="term">terms</tref> may be
+   defined using an <tref>expanded term definition</tref> to allow for additional information
    associated with the <tref>term</tref> to be specified (see also
    <a href="#type-coercion"></a> and
    <a href="#sets-and-lists"></a>).</p>
 
-<p>Instead of using a string representation of an IRI, the IRI MAY be
-specified using a <tref>JSON object</tref> having an <code>@id</code> key.
-The value of the <code>@id</code> key MUST be either a <tref>term</tref>, a
-<tref>compact IRI</tref>, or an <tref>absolute IRI</tref>. Such
+<p>Instead of using a string representation of an IRI, the IRI may be
+specified using a <tref>JSON object</tref> having an <code>@id</code> key,
+and a <tref>term</tref>, a <tref>compact IRI</tref>, or an
+<tref>absolute IRI</tref> as value. Such
 an object is called a <tref>node reference</tref>.</p>
 
 <pre class="example" data-transform="updateExample"
@@ -1641,8 +1638,8 @@
 </pre>
 
 <p>This allows additional information to be associated with the term. This
-  MAY be used for <a href="#type-coercion"></a>,
-  <a href="#sets-and-lists"></a>), or to associate language
+  may be used for <a href="#type-coercion"></a>,
+  <a href="#sets-and-lists"></a>, or to associate language
   information with a <tref>term</tref> as shown in the following example:</p>
 
 <pre class="example" data-transform="updateExample"
@@ -1672,12 +1669,12 @@
   <code>en</code>, and <em>Nindža</em> with the language code <code>cs</code>.
   The value of <code>name</code>, <em>Yagyū Muneyoshi</em> wouldn't be
   associated with any language code since <code>@language</code> was reset to
-  <tref>null</tref> in the expanded term definition.</p>
-
-<p>Expanded terms MAY also be defined using <tref title="compact_iri">compact IRIs</tref> or
+  <tref>null</tref> in the <tref>expanded term definition</tref>.</p>
+
+<p>Expanded terms may also be defined using <tref title="compact_iri">compact IRIs</tref> or
   <tref title="absolute_IRI">absolute IRIs</tref> as keys. If the definition does not include an
   <code>@id</code> key, the expanded IRI is determined by performing expansion of the key
-  within the current active context. This mechanism is mainly used to associate type or language
+  within the current <tref>active context</tref>. This mechanism is mainly used to associate type or language
   information with a <tref>compact IRI</tref> or an <tref>absolute IRI</tref>.</p>
 
 <p class="note">While it is possible to define a
@@ -1692,24 +1689,24 @@
 
 <p>JSON-LD supports the coercion of values to particular data types.
 Type <tdef>coercion</tdef> allows someone deploying JSON-LD to coerce the incoming or
-outgoing values to the proper data type based on a mapping of data type <tref>IRI</tref>s to
-<tref>term</tref>s. Using type coercion, value representation is preserved without requiring
+outgoing values to the proper data type based on a mapping of data type <tref title="IRI">IRIs</tref> to
+<tref title="term">terms</tref>. Using type coercion, value representation is preserved without requiring
 the data type to be specified with each piece of data.</p>
 
 <p>Type coercion is specified within an <a href="#expanded-term-definition"></a>
-  using the <code>@type</code> key. The value of this key represents a type IRI and MUST take the form of
-  a <tref>term</tref>, <tref>compact IRI</tref>, <tref>absolute IRI</tref>, or the <tref>keyword</tref> <code>@id</code>. Specifying
-  <code>@id</code> indicates that within the body of a JSON-LD document, a string value of a <tref>term</tref> coerced to
+  using the <code>@type</code> key. The value of this key expands to an <tref>IRI</tref>.
+  Alternatively, the <tref>keyword</tref> <code>@id</code> may be used as value to indicate
+  that within the body of a JSON-LD document, a string value of a <tref>term</tref> coerced to
   <code>@id</code> is to be interpreted as an <tref>IRI</tref>.</p>
 
 <p><tref title="term">Terms</tref> or <tref title="compact_iri">compact IRIs</tref> used as the value of a
-  <code>@type</code> key MAY be defined within the same context. This means that one may specify a
+  <code>@type</code> key may be defined within the same context. This means that one may specify a
   <tref>term</tref> like <code>xsd</code> and then use <code>xsd:integer</code> within the same
   context definition - the JSON-LD processor will be able to determine the proper expansion for
   <code>xsd:integer</code>.</p>
 
 <p>The example below demonstrates how a JSON-LD author can coerce values to
-<tref>typed value</tref>s, IRIs and lists.</p>
+<tref title="typed value">typed values</tref>, IRIs and lists.</p>
 
 <pre class="example" data-transform="updateExample"
      title="Expanded term definition with types">
@@ -1824,9 +1821,8 @@
   <code>http://example.org/river</code>, but this usage is discouraged because it would lead to a
   great deal of confusion among developers attempting to understand the JSON-LD document.</p>
 
-<p>Type coercion is performed using the unexpanded value of the key,
-  which MUST have an exact match for an entry in the
-  <tref>active context</tref>.</p>
+<p>Type coercion is performed using the unexpanded value of the key, which has to match exactly
+  an entry in the <tref>active context</tref>.</p>
 
 </section>
 
@@ -1904,7 +1900,7 @@
   <p>In general, normal IRI expansion rules apply
     anywhere an IRI is expected (see <a href="#iris"></a>). Within
     a <tref>context</tref> definition, this can mean that terms defined
-    within the context MAY also be used within that context as long as
+    within the context may also be used within that context as long as
     there are no circular dependencies. For example, it is common to use
     the <code>xsd</code> namespace when defining <tref>typed value</tref>s:</p>
 <pre class="example" data-transform="updateExample"
@@ -1934,7 +1930,7 @@
   and used as a <tref>prefix</tref> for the <code>@type</code> coercion
   of the <code>age</code> property.</p>
 
-<p><tref>Term</tref>s MAY also be used when defining the IRI of another
+<p><tref title="term">Terms</tref> may also be used when defining the IRI of another
 <tref>term</tref>:</p>
 
 <pre class="example" data-transform="updateExample">
@@ -1962,7 +1958,7 @@
 </pre>
 
 <p><tref title="compact iri">Compact IRIs</tref>
-  and <tref title="iri">IRIs</tref> MAY be used on the left-hand side of a
+  and <tref title="iri">IRIs</tref> may be used on the left-hand side of a
   <tref>term</tref> definition.</p>
 
 <pre class="example" data-transform="updateExample">
@@ -2001,7 +1997,7 @@
 </p>
 
 <p>
-<tref title="absolute iri">Absolute IRIs</tref> MAY also be used in the key position in a <tref>context</tref>:
+<tref title="absolute iri">Absolute IRIs</tref> may also be used in the key position in a <tref>context</tref>:
 </p>
 
 <pre class="example" data-transform="updateExample">
@@ -2028,19 +2024,18 @@
 </pre>
 
 <p>
-In order for the <tref>absolute IRI</tref> to match above, the <tref>absolute IRI</tref> MUST also
-be used in the JSON-LD document. Also note that <code>foaf:homepage</code>
+In order for the <tref>absolute IRI</tref> to match above, the <tref>absolute IRI</tref> needs to be used in the <tref>JSON-LD document</tref>. Also note that <code>foaf:homepage</code>
 will not use the <code>{ "@type": "@id" }</code> declaration because
 <code>foaf:homepage</code> is not the same as
-<code>http://xmlns.com/foaf/0.1/homepage</code>. That is, a JSON-LD
-processor will use direct string comparison when looking up
-<tref>term</tref>s in a <tref>context</tref> before it applies the
+<code>http://xmlns.com/foaf/0.1/homepage</code>. That is, a <tref>JSON-LD
+processor</tref> will use direct string comparison when looking up
+<tref title="term">terms</tref> in a <tref>context</tref> before it applies the
 <tref>prefix</tref> lookup mechanism.
 </p>
 
 <p>The only exception for using terms in the <tref>context</tref> is that
-  they MUST NOT be used in a circular manner. That is,
-  a definition of <em>term-1</em> MUST NOT depend on the
+  circular definitions are not allowed. That is,
+  a definition of <em>term-1</em> cannot depend on the
   definition of <em>term-2</em> if <em>term-2</em> also depends on
   <em>term-1</em>. For example, the following <tref>context</tref> definition
   is illegal:</p>
@@ -2062,7 +2057,7 @@
 <h2>Sets and Lists</h2>
 
 <p>A JSON-LD author can express multiple values in a compact way by using
-  <tref>array</tref>s. Since graphs do not describe ordering for links
+  <tref title="array">arrays</tref>. Since graphs do not describe ordering for links
   between nodes, arrays in JSON-LD do not provide an ordering of the
   contained elements by default. This is exactly the opposite from regular JSON
   arrays, which are ordered by default. For example, consider the following
@@ -2201,7 +2196,7 @@
 
 <p>Similarly to <code>@list</code>, there exists the <tref>keyword</tref> <code>@set</code> to
   describe unordered sets. While its use in the body of a JSON-LD document
-  represents just syntactic sugar that MUST be optimized away when processing
+  represents just syntactic sugar optimized away when processing
   the document, it is very helpful when used within the context of a document.
   Values of terms associated with a <code>@set</code> or <code>@list</code> container
   are always represented in the form of an <tref>array</tref> - even if there is just a
@@ -2222,7 +2217,7 @@
   <p><tdef>Embedding</tdef> is a JSON-LD feature that allows an author to
     use <tref title="node definition">node definitions</tref> as
     <tref>property</tref> values. This is a commonly used mechanism for
-    creating a parent-child relationship between two <tref>node</tref>s.</p>
+    creating a parent-child relationship between two <tref title="node">nodes</tref>.</p>
 
   <p>The example shows two nodes related by a property from the first node:</p>
 
@@ -2242,7 +2237,7 @@
   </pre>
 
   <p>
-    A <tref>node definition</tref>, like the one used above, MAY be used in
+    A <tref>node definition</tref>, like the one used above, may be used in
     any value position in the body of a JSON-LD document.</p>
 </section>
 
@@ -2252,7 +2247,7 @@
   <p>At times, it is necessary to make statements about a <tref>JSON-LD graph</tref>
     itself, rather than just a single <tref>node</tref>. This can be done by
     grouping a set of <tref title="node">nodes</tref> using the <code>@graph</code>
-    <tref>keyword</tref>. A developer MAY also name data expressed using the
+    <tref>keyword</tref>. A developer may also name data expressed using the
     <code>@graph</code> <tref>keyword</tref> by pairing it with an
     <code>@id</code> <tref>keyword</tref> as shown in the following example:</p>
 
@@ -2456,7 +2451,7 @@
 <h2>Aliasing Keywords</h2>
 
 <p>Each of the JSON-LD <tref title="keyword">keywords</tref>,
-except for <code>@context</code>, MAY be aliased to application-specific
+except for <code>@context</code>, may be aliased to application-specific
 keywords. This feature allows legacy JSON content to be utilized
 by JSON-LD by re-using JSON keys that already exist in legacy documents.
 This feature also allows developers to design domain-specific implementations
@@ -2643,8 +2638,7 @@
 
 <p>A <tref>JSON-LD document</tref> MUST be a single <tref>node definition</tref>
   or a JSON <tref>array</tref> containing a set of one or more
-  <tref title="node definition">node definitions</tref>.
-  (@@@ plus @graph exception to the rule?)</p>
+  <tref title="node definition">node definitions</tref>.</p>
 <pre class="example" data-transform="updateExample"
      title="Simple node definition">
 <!--
@@ -3057,13 +3051,16 @@
 <p>If the <tref>expanded term definition</tref> contains the <code>@id</code> <tref>keyword</tref>,
   its value MUST be an <tref>IRI</tref>, a <tref>compact IRI</tref>, a <tref>term</tref> defined in the defining <tref>context definition</tref> or the <tref>active context</tref>, or an <tref>array</tref> composed of any of the previous allowed values.</p>
 <p>If the <tref>expanded term definition</tref> contains the <code>@type</code> <tref>keyword</tref>,
-  its value MUST be an <tref>absolute IRI</tref>, a <tref>compact IRI</tref>, or a <tref>term</tref> defined in the defining <tref>context definition</tref> or the <tref>active context</tref>.</p>
+  its value MUST be an <tref>absolute IRI</tref>, a <tref>compact IRI</tref>, a <tref>term</tref> defined in the defining <tref>context definition</tref> or the <tref>active context</tref>, or the <code>@id</code> <tref>keyword</tref>.</p>
 <p>If the <tref>expanded term definition</tref> contains the <code>@language</code> <tref>keyword</tref>,
   its value MUST have the lexical form described in [[!BCP47]] or be <tref>null</tref>.</p>
 <p>If the <tref>expanded term definition</tref> contains the <code>@container</code> <tref>keyword</tref>,
   its value MUST be either <code>@list</code>, <code>@set</code>, <code>@language</code>, or be <tref>null</tref>.
   If the value is <code>@language</code>, when the <tref>term</tref> is used outside of the <code>@context</code>, the
   associated value MUST be a <tref>language map</tref>.</p>
+
+<p><tref title="term">Terms</tref> MUST NOT be used in a circular manner. That is, the definition of a term cannot depend on the definition of another term if that other term also depends on the first term.</p>
+
 <p>See <a href="#the-context"></a> and <a href="#expanded-term-definition"></a>
   for further discussion of contexts.</p>
 </section>