Merge remote-tracking branch 'origin/master'
authorGregg Kellogg <gregg@kellogg-assoc.com>
Wed, 21 Mar 2012 13:54:45 -0700
changeset 395 d94be73424be
parent 392 61052a6dc46f (current diff)
parent 394 dedef0a96c18 (diff)
child 396 fd3256bf8f14
Merge remote-tracking branch 'origin/master'
spec/latest/json-ld-api/index.html
--- a/spec/latest/json-ld-api/index.html	Wed Mar 21 13:54:26 2012 -0700
+++ b/spec/latest/json-ld-api/index.html	Wed Mar 21 13:54:45 2012 -0700
@@ -821,6 +821,7 @@
     <li>Create a new, empty <tref>local context</tref>.</li>
     <li>Let <em>value</em> be the value of <code>@context</code>
       <ol id="process-context" class="algorithm">
+        <li>If <em>value</em> equals <code>null</code>, reset the <tref>active context</tref> to the <tref>initial context</tref></li>
         <li>If <em>value</em> is an <tref>array</tref>, process
           each element as <em>value</em>, in order using <a href="#process-context">Step 2</a>.</li>
         <li>If <em>value</em> is a simple <tref>string</tref>, it MUST have a lexical form of <tref>absolute IRI</tref>.
@@ -873,7 +874,7 @@
                   </ol>
                 </li>
                 <li>Merge the <tref>local context</tref> into the <tref>active context</tref>.</li>
-                <li>Repeat <a href="#object-context">Step 2.3.2</a> until no entries are added to the <tref>local
+                <li>Repeat <a href="#object-context">Step 3.3.2</a> until no entries are added to the <tref>local
                   context</tref>.</li>
               </ol>
             </li>
@@ -955,24 +956,24 @@
   <p>The algorithm for expanding a <em>value</em> takes an <tref>active property</tref>
     and <tref>active context</tref>. It is implemented as follows:</p>
   <ol class="algorithm">
-    <li>If <em>value</em> is <tref>true</tref>, <tref>false</tref> or <tref>number</tref>, expand the value by
-      adding a two new key-value pairs. The first key-value pair will be <code>@value</code> and
-      the string representation of <em>value</em>. The second key-value pair will be <code>@type></code>,
-      and the expanded version of <code>xsd:boolean</code>, <code>xsd:integer</code>, or <code>xsd:double</code>,
-      depending on <em>value</em>.</li>
-    <li>Otherwise, if <tref>active property</tref> is the target of an <code>@id</code> coercion,
-      expand the value by adding a new key-value pair where the
-      key is <code>@id</code> and the value is the expanded IRI according to the <a href="#iri-expansion">IRI
-      Expansion</a> rules.</li>
+    <li>If <em>value</em> is a <tref>number</tref> and the <tref>active property</tref> is the target of typed literal
+      coercion to <code>xsd:integer</code> or <code>xsd:double</code>, expand the value into an object with
+      two key-value pairs. The first key-value pair will be <code>@value</code> and the string representation of
+      <em>value</em> as defined in the section <a href="#data-round-tripping">Data Round Tripping</a>. The second
+      key-value pair will be <code>@type</code> and the associated coercion datatype expanded according to the
+      <a href="#iri-expansion">IRI Expansion</a> rules.</li>
+    <li>Otherwise, if <tref>active property</tref> is the target of an <code>@id</code> coercion, expand the value
+      into an object with a key-value pair where the key is <code>@id</code> and the value is the expanded
+      IRI according to the <a href="#iri-expansion">IRI Expansion</a> rules.</li>
     <li>Otherwise, if <tref>active property</tref> is the target of typed literal coercion,
-      expand <em>value</em> by adding two new key-value pairs. The first key-value pair will be <code>@value</code>
-      and the unexpanded value. The second key-value pair will be <code>@type</code> and the associated coercion
+      expand <em>value</em> into an object with key-value pairs. The first key-value pair will be <code>@value</code>
+      and the unexpanded <em>value</em>. The second key-value pair will be <code>@type</code> and the associated coercion
       datatype expanded according to the <a href="#iri-expansion">IRI Expansion</a> rules.</li>
-    <li>Otherwise, if the <tref>active context</tref> has a <code>@language</code>,
-      expand <em>value</em> by adding two new key-value pairs. The first key-value pair will be <code>@value</code>
-      and the unexpanded value. The second key-value pair will be <code>@language</code> and value of
-      <code>@language</code> from the <tref>active context</tref>.</li> <li>Otherwise, <em>value</em> is already
-      expanded.</li>
+    <li>Otherwise, if <em>value</em> is a <tref>string</tref> and the <tref>active property</tref> is not the target of
+      typed literal coercion but target of language tagging, expand <em>value</em> into an object with two
+      key-value pairs. The first key-value pair will be <code>@value</code> and the unexpanded <em>value</em>.
+      The second key-value pair will be <code>@language</code> and value of the language tagging from the <tref>active context</tref>.</li>
+    <li>Otherwise, <em>value</em> is already expanded.</li>
   </ol>
 </section>
 
@@ -1667,20 +1668,23 @@
 
 <h3>Data Round Tripping</h3>
 
-<p>When normalizing <strong>xsd:double</strong> values, implementers MUST
-ensure that the normalized value is a string. In order to generate the
-string from a <strong>double</strong> value, output equivalent to the
-<code>printf("%1.6e", value)</code> function in C MUST be used where
-<strong>"%1.6e"</strong> is the string formatter and <strong>value</strong>
-is the value to be converted.</p>
+<p>When normalizing numbers with fractions or coercing numbers to <strong>xsd:integer</strong>
+or <strong>xsd:double</strong>, implementers MUST ensure that the resulting value is a string.
+In order to generate the string from a <tref>number</tref>, an algorithm creating an output
+equivalent to the <code>printf("%1.16e", value)</code> function in C MUST be used where
+<strong>"%1.16e"</strong> is the string formatter and <strong>value</strong>
+is the number to be converted.</p>
 
-<p>To convert the a double value in JavaScript, implementers can use the
+<p class="issue"><a href="https://github.com/json-ld/json-ld.org/issues/81">ISSUE-81</a>:
+  This information might be wrong. We might need to use the canonical form of xsd:double.</p>
+
+<p>To convert the number in JavaScript, implementers can use the
 following snippet of code:</p>
 
 <pre class="example" data-transform="updateExample">
 <!--
 // the variable 'value' below is the JavaScript native double value that is to be converted
-(value).toExponential(6).replace(/(e(?:\+|-))([0-9])$/, '$10$2')
+(value).toExponential(16).replace(/(e(?:\+|-))([0-9])$/, '$10$2')
 -->
 </pre>
 
--- a/spec/latest/json-ld-syntax/index.html	Wed Mar 21 13:54:26 2012 -0700
+++ b/spec/latest/json-ld-syntax/index.html	Wed Mar 21 13:54:45 2012 -0700
@@ -1692,54 +1692,6 @@
 </section>
 
 <section>
-<h2>Automatic Typing</h2>
-
-<p>Since JSON is capable of expressing typed information such as doubles,
-integers, and boolean values. As demonstrated below, JSON-LD utilizes that
-information to create <tref>typed value</tref>s:</p>
-
-<pre class="example" data-transform="updateExample">
-<!--
-{
-...
-  // The following two values are automatically converted to a type of xsd:double
-  // and both values are equivalent to each other.
-  "measure:cups": ****5.3****,
-  "measure:cups": ****5.3e0****,
-  // The following value is automatically converted to a type of xsd:double as well
-  "space:astronomicUnits": ****6.5e73****,
-  // The following value is never converted to a language-native type
-  "measure:stones": ****{ "@value": "4.8", "@type": "xsd:decimal" }****,
-  // This value is automatically converted to having a type of xsd:integer
-  "chem:protons": ****12****,
-  // This value is automatically converted to having a type of xsd:boolean
-  "sensor:active": ****true****,
-...
-}
--->
-</pre>
-
-<p class="note">When dealing with a number of modern programming languages,
-including JavaScript ECMA-262, there is no distinction between
-<strong>xsd:decimal</strong> and <strong>xsd:double</strong> values. That is,
-the <tref>number</tref> <code>5.3</code> and the <tref>number</tref>
-<code>5.3e0</code> are treated as if they were the same. When converting from
-JSON-LD to a language-native format and back, type information is lost in a
-number of these languages. Thus, one could say that <code>5.3</code> is a
-<strong>xsd:decimal</strong> and <code>5.3e0</code> is an
-<strong>xsd:double</strong> in JSON-LD, but when both values are
-converted to a language-native format the type difference between the two
-is lost because the machine-level representation will almost always be a
-<strong>double</strong>.
-Implementers should be aware of this potential round-tripping issue between
-<strong>xsd:decimal</strong> and <strong>xsd:double</strong>. Specifically
-objects with a type of <strong>xsd:decimal</strong> MUST NOT be converted
-to a language native type.
-</p>
-
-</section>
-
-<section>
 <h2>Type Coercion</h2>
 
 <p>JSON-LD supports the coercion of values to particular data types.