Markus feedback on recent Conformance/Grammar updates incorporated.
- Created issue #184 to discuss the definition of a JSON-LD
processor. The doc references that issue in the meantime.
- Incorporated Markus feedback to clarify when a JSON object with
a null value is ignored
- Re-introduced statement that discourages the use of empty terms
in "Context" section. I left it in the grammar as well because that
also seems the right place to mention it but, technically speaking,
it could be removed from there since it's not a normative binding.
--- a/spec/latest/json-ld-syntax/index.html Mon Nov 05 11:03:51 2012 +0100
+++ b/spec/latest/json-ld-syntax/index.html Wed Nov 07 09:01:13 2012 +0100
@@ -527,7 +527,7 @@
<dt><tdef>null</tdef></dt>
<dd>The <code>null</code> value. Unless otherwise specified, a key-value
pair in the body of a JSON-LD document whose value is <em>null</em>
- has the same meaning as if the key was not defined. If <code>@value</code>,
+ has the same meaning as if the key-value pair was not defined. If <code>@value</code>,
<code>@list</code>, or <code>@set</code> is set to <em>null</em> in
expanded form, then the entire <tref>JSON object</tref> is ignored.</dd>
</dl>
@@ -592,9 +592,10 @@
<p>The JSON-LD Syntax specification describes the conformance criteria for JSON-LD documents (relevant to authors and authoring tool implementors) and processors (relevant to Linked Data tools implementors).</p>
-<p>A <tdef>JSON-LD document</tdef> is a JSON document that expresses <tref>Linked Data</tref> in JSON. A JSON-LD document complies with this specification if it follows the normative statements for documents defined in sections <a href="#basic-concepts"></a>, <a href="#advanced-concepts"></a> and <a href="#json-ld-grammar"></a>. For convenience, normative statements for documents are often phrased as statements on the properties of the document.</p>
+<p>A <tdef>JSON-LD document</tdef> is a JSON document that expresses <tref>Linked Data</tref> in JSON. A JSON-LD document complies with this specification if it follows the normative statements for documents defined in sections <a href="#referencing-contexts-from-json-documents"></a> and <a href="#json-ld-grammar"></a>. For convenience, normative statements for documents are often phrased as statements on the properties of the document.</p>
<p>A <tdef>JSON-LD processor</tdef> parses a <tref>JSON-LD document</tref> and generates the corresponding <tref>JSON-LD graph</tref> (mapping terms to IRIs and coercing values). A JSON-LD processor complies with this specification if it follows the normative statements for processors. Statements that are applicable to a JSON-LD processor are identified in this document by use of the term "JSON-LD processor" in the singular or plural.</p>
+<p class="issue" data-number="184">The definition of JSON-LD processor is under discussion</p>
<p>The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this Recommendation have the meaning defined in [[!RFC2119]].</p>
@@ -619,7 +620,11 @@
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.
+ page, API or database in which it resides.</p>
+
+<p>Note that the use of empty <tref title="term">terms</tref> (<code>""</code>)
+ is discouraged as not all programming languages are able to handle empty
+ property names.
</p>
<p>In a JSON-LD document, the mapping between <tref title="term">terms</tref> and