Enumerate features at risk
authorMarkus Lanthaler <mark_lanthaler@gmx.net>
Tue, 02 Apr 2013 14:56:54 +0200
changeset 1526 ec85aec5d78c
parent 1525 ed57662b5966
child 1527 f2b15a252b16
Enumerate features at risk

The descriptions haven't been updated yet.

This addresses #224 and #234.
spec/latest/json-ld-api/index.html
spec/latest/json-ld/index.html
--- a/spec/latest/json-ld-api/index.html	Tue Apr 02 14:40:14 2013 +0200
+++ b/spec/latest/json-ld-api/index.html	Tue Apr 02 14:56:54 2013 +0200
@@ -40,6 +40,7 @@
       // extraCSS: [],
 
       issueBase: "https://github.com/json-ld/json-ld.org/issues/",
+      // atRiskBase: "https://github.com/json-ld/json-ld.org/issues/",
 
       // editors, add as many as you like
       // only "name" is required
@@ -127,14 +128,6 @@
     is an expectation that they could be used in a production system within the
     next six months.</p>
 
-  <p class="issue">It is important for readers to understand that the scope of this
-    document is currently under debate and new features may be added to the specification.
-    Existing features may be modified heavily or removed entirely from the
-    specification upon further review and feedback from the broader community.
-    This is a work in progress and publication as a Working Draft
-    does not require that all Working Group members agree on the content of the
-    document.</p>
-
   <p>There are a number of ways that one may participate in the development of
     this specification:</p>
 
@@ -915,13 +908,18 @@
               <code class="error"><a href="#idl-def-JsonLdErrorCode.invalid-local-context">invalid local context</a></code>
               error has been detected and processing is aborted.</li>
             <li>If <i>context</i> has an <code>@base</code> key:
-              <p class="issue atrisk" data-number="223" title="Feature at risk">This feature is
-                at risk as the fact that a document may have multiple base IRIs
-                is potentially confusing for developers. It is also being discussed whether
-                relative IRIs are allowed as values of <code>@base</code> or whether
-                the empty string should be used to explicitly specify that there isn't
-                a base IRI, which could be used to ensure that relative IRIs remain
-                relative when expanding.</p>
+              <div class="issue atrisk" data-number="1" title="@base keyword">
+                <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+                  this specification based on feedback. Please send feedback to
+                  <a href="mailto:[email protected]">[email protected]</a>.
+                  For the current status see
+                  <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+                <p>This feature is at risk as the fact that a document may have multiple base
+                  IRIs is potentially confusing for developers. It is also being discussed whether
+                  relative IRIs are allowed as values of <code>@base</code> or whether the
+                  empty string should be used to explicitly specify that there isn't a base IRI,
+                  which could be used to ensure that relative IRIs remain relative when expanding.</p>
+              </div>
               <ol class="algorithm">
                 <li>Initialize <i>value</i> to the value associated with the
                   <code>@base</code> key.</li>
@@ -3069,13 +3067,19 @@
 
     <p>This algorithms converts a JSON-LD document to an <tref>RDF dataset</tref>.</p>
 
-    <p class="issue atrisk" data-number="217" title="Feature at risk">RDF does not
-      currently allow a <tref>blank node identifier</tref> to be used as
-      <tref>graph name</tref> or <tref>property</tref>. Implementations might
-      convert such <tref title="blank node identifier">blank node identifiers</tref>
-      to <tref title="IRI">IRIs</tref> by minting new "Skolem IRIs" as per
-      <cite><a href="http://www.w3.org/TR/rdf11-concepts/#section-skolemization">Replacing Blank Nodes with IRIs</a></cite>
-      of [[RDF11-CONCEPTS]].</p>
+    <div class="issue atrisk" data-number="3" title="Allow blank nodes to be used as graph name or property">
+      <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+        this specification based on feedback. Please send feedback to
+        <a href="mailto:[email protected]">[email protected]</a>.
+        For the current status see
+        <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+      <p>RDF does not currently allow a <tref>blank node identifier</tref> to be
+        used as <tref>graph name</tref> or <tref>property</tref>. Implementations
+        might convert such <tref title="blank node identifier">blank node identifiers</tref>
+        to <tref title="IRI">IRIs</tref> by minting new "Skolem IRIs" as per
+        <cite><a href="http://www.w3.org/TR/rdf11-concepts/#section-skolemization">Replacing Blank Nodes with IRIs</a></cite>
+        of [[RDF11-CONCEPTS]].</p>
+    </div>
 
     <section class="informative">
       <h3>Overview</h3>
@@ -3281,16 +3285,23 @@
       <tref>default graph</tref> and zero or more
       <tref title="named graph">named graphs</tref> into a JSON-LD document.</p>
 
-    <p class="issue atrisk" title="Feature at risk">In the interest of space and
-      simplicity, the steps necessary for handling lists of lists have been omitted.
-      Such lists and their elements must, recursively, be handled like other lists.
-      Lists of lists can, however, not be represented in JSON-LD using <code>@list</code>;
-      they have to be represented as a set of interlinked node objects using RDF's
-      <code>rdf:first</code> and <code>rdf:rest</code> properties.
-      <em>NOTE:</em> this is an at-risk feature. The Working Group might either require
-      handling of lists-of-lists or forbid them in JSON-LD. Implementers please send
-      reports of whether you are able to implement handling for lists-of-lists or
-      would instead request such structures be disallowed.</p>
+    <div class="issue atrisk" data-number="5" title="Converting list of lists to JSON-LD ">
+      <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+        this specification based on feedback. Please send feedback to
+        <a href="mailto:[email protected]">[email protected]</a>.
+        For the current status see
+        <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+      <p>In the interest of space and
+        simplicity, the steps necessary for handling lists of lists have been omitted.
+        Such lists and their elements must, recursively, be handled like other lists.
+        Lists of lists can, however, not be represented in JSON-LD using <code>@list</code>;
+        they have to be represented as a set of interlinked node objects using RDF's
+        <code>rdf:first</code> and <code>rdf:rest</code> properties.
+        <em>NOTE:</em> this is an at-risk feature. The Working Group might either require
+        handling of lists-of-lists or forbid them in JSON-LD. Implementers please send
+        reports of whether you are able to implement handling for lists-of-lists or
+        would instead request such structures be disallowed.</p>
+    </div>
 
     <section class="informative">
       <h3>Overview</h3>
@@ -3852,13 +3863,19 @@
           <em>input</em> if it is an IRI. If not specified and <em>input</em> is not
           an IRI, the base IRI defaults to the current document IRI if in a browser context,
           or the empty string if there is no document context.
-          <p class="issue atrisk" title="Feature at risk" data-number="223">The default value of this option
-            implies that all IRIs that cannot be compacted otherwise are transformed to relative IRIs
-            during compaction. To avoid that data is being lost, developers thus have to store the
-            base IRI along with the compacted document. This might be problematic in practice and
-            thus the default behavior might be changed in future. Furthermore, the relationship
-            of this option to the <code>@base</code> keyword (which is at risk) should be further
-            investigated.</p>
+          <div class="issue atrisk" data-number="4" title="Default value of base member in JsonLdOptions">
+            <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+              this specification based on feedback. Please send feedback to
+              <a href="mailto:[email protected]">[email protected]</a>.
+              For the current status see
+              <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+            <p>The default value of this option implies that all IRIs that cannot be compacted otherwise
+              are transformed to relative IRIs during compaction. To avoid that data is being lost,
+              developers thus have to store the base IRI along with the compacted document. This might
+              be problematic in practice and thus the default behavior might be changed in future.
+              Furthermore, the relationship of this option to the <code>@base</code> keyword
+              (which is at risk) should be further investigated.</p>
+          </div>
         </dd>
         <dt>boolean compactArrays = true</dt>
         <dd>If set to <code>true</code>, the JSON-LD processor replaces arrays with just
--- a/spec/latest/json-ld/index.html	Tue Apr 02 14:40:14 2013 +0200
+++ b/spec/latest/json-ld/index.html	Tue Apr 02 14:56:54 2013 +0200
@@ -35,6 +35,7 @@
       // lcEnd: "2009-08-05",
 
       issueBase: "https://github.com/json-ld/json-ld.org/issues/",
+      // atRiskBase: "https://github.com/json-ld/json-ld.org/issues/",
 
       // if you want to have extra CSS, append them to this list
       // it is recommended that the respec.css stylesheet be kept
@@ -89,7 +90,8 @@
 </script>
 <style type="text/css">
   .diff { font-weight:bold; color:#0a3; }
-  table, thead, tr, td { padding: 5px; border-width: 1px; border-spacing: 0px; border-style: solid; border-collapse: collapse;}
+  table, thead, tr, td { padding: 5px; border-width: 1px; border-spacing: 0px; border-style: solid; border-collapse: collapse; }
+  .atrisk-head { font-style: italic; }
 </style>
 </head>
 
@@ -788,12 +790,18 @@
 <section class="informative">
   <h2>Base IRI</h2>
 
-  <p class="issue atrisk" data-number="223" title="Feature at risk">This feature is
-    at risk as the fact that a document may have multiple base IRIs is potentially
-    confusing for developers. It is also being discussed whether relative IRIs
-    are allowed as values of <code>@base</code> or whether the empty string
-    should be used to explicitly specify that there isn't a base IRI, which
-    could be used to ensure that relative IRIs remain relative when expanding.</p>
+  <div class="issue atrisk" data-number="1" title="@base keyword">
+    <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+      this specification based on feedback. Please send feedback to
+      <a href="mailto:[email protected]">[email protected]</a>.
+      For the current status see
+      <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+    <p>This feature is at risk as the fact that a document may have multiple base
+      IRIs is potentially confusing for developers. It is also being discussed whether
+      relative IRIs are allowed as values of <code>@base</code> or whether the
+      empty string should be used to explicitly specify that there isn't a base IRI,
+      which could be used to ensure that relative IRIs remain relative when expanding.</p>
+  </div>
 
   <p>JSON-LD allows <tref>IRI</tref>s to be specified in a relative form which is
     resolved against the document base according
@@ -1967,7 +1975,14 @@
 <section class="informative">
   <h2>Reverse Properties</h2>
 
-  <p class="issue atrisk">This feature is at risk.</p>
+  <div class="issue atrisk" data-number="2" title="Reverse properties">
+    <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+      this specification based on feedback. Please send feedback to
+      <a href="mailto:[email protected]">[email protected]</a>.
+      For the current status see
+      <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+    <p>This feature is at risk.</p>
+  </div>
 
   <p>JSON-LD serializes directed <tref title="JSON-LD graph">graphs</tref>. That means that
     every <tref>property</tref> points from a <tref>node</tref> to another <tref>node</tref>
@@ -2712,13 +2727,19 @@
       <tref title="JSON-LD value">JSON-LD values</tref>.</li>
   </ul>
 
-  <p class="issue atrisk" data-number="217">RDF does not currently allow a
-    <tref>blank node identifier</tref> to be used as <tref>graph name</tref> or
-    <tref>property</tref>. Implementations might convert such
-    <tref title="blank node identifier">blank node identifiers</tref>
-    to <tref title="IRI">IRIs</tref> by minting new "Skolem IRIs" as per
-    <cite><a href="http://www.w3.org/TR/rdf11-concepts/#section-skolemization">Replacing Blank Nodes with IRIs</a></cite>
-    of [[RDF11-CONCEPTS]].</p>
+  <div class="issue atrisk" data-number="3" title="Allow blank nodes to be used as graph name or property">
+    <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+      this specification based on feedback. Please send feedback to
+      <a href="mailto:[email protected]">[email protected]</a>.
+      For the current status see
+      <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+    <p>RDF does not currently allow a <tref>blank node identifier</tref> to be
+      used as <tref>graph name</tref> or <tref>property</tref>. Implementations
+      might convert such <tref title="blank node identifier">blank node identifiers</tref>
+      to <tref title="IRI">IRIs</tref> by minting new "Skolem IRIs" as per
+      <cite><a href="http://www.w3.org/TR/rdf11-concepts/#section-skolemization">Replacing Blank Nodes with IRIs</a></cite>
+      of [[RDF11-CONCEPTS]].</p>
+  </div>
 
   <p><tref title="JSON-LD document">JSON-LD documents</tref> MAY contain data that cannot be
     represented by the <tref title="JSON-LD data model">data model</tref> defined above.
@@ -3024,12 +3045,18 @@
   <p>If the <tref>context definition</tref> has a <code>@base</code> key,
     its value MUST be an <tref>absolute IRI</tref> or <tref>null</tref>.</p>
 
-  <p class="issue atrisk" data-number="223" title="Feature at risk">This feature is
-    at risk as the fact that a document may have multiple base IRIs is potentially
-    confusing for developers. It is also being discussed whether relative IRIs
-    are allowed as values of <code>@base</code> or whether the empty string
-    should be used to explicitly specify that there isn't a base IRI, which
-    could be used to ensure that relative IRIs remain relative when expanding.</p>
+  <div class="issue atrisk" data-number="1" title="@base keyword">
+    <p class="atrisk-head">Note: This feature is "at risk" and may be removed from
+      this specification based on feedback. Please send feedback to
+      <a href="mailto:[email protected]">[email protected]</a>.
+      For the current status see
+      <a href="http://www.w3.org/2011/rdf-wg/wiki/JSON-LD_Features_at_Risk">features "at risk" in JSON-LD 1.0</a></p>
+    <p>This feature is at risk as the fact that a document may have multiple base
+      IRIs is potentially confusing for developers. It is also being discussed whether
+      relative IRIs are allowed as values of <code>@base</code> or whether the
+      empty string should be used to explicitly specify that there isn't a base IRI,
+      which could be used to ensure that relative IRIs remain relative when expanding.</p>
+  </div>
 
   <p>If the <tref>context definition</tref> has a <code>@vocab</code> key,
     its value MUST be a <tref>absolute IRI</tref>, a <tref>compact IRI</tref>,