--- a/spec/identity-respec.html	Sun Nov 18 21:20:09 2012 -0500
+++ b/spec/identity-respec.html	Sun Nov 18 22:01:56 2012 -0500
@@ -374,8 +374,6 @@
 
 <dt><tdef>WebID</tdef></dt>
 <dd>A WebID is a URI with an HTTP or HTTPS scheme, containing a URI fragment identifier (i.e. a # symbol) and which uniquely denotes an Agent (Person, Organisation, Group, Device, etc.). The URI without the fragment identifier denotes the WebID <tref>Profile page</tref>.
-
-<p class="issue">Due to legacy support for URIs which do not contain URI fragment identifiers, verifiers MUST not fail when dereferencing hashless URIs, though they MAY flag them as potentially impacting on performance. The use of hashless URIs is deprecated and must be avoided when creating new WebIDs.</p>
 </dd>
 
 <dt><tdef>WebID Profile</tdef> or <tdef>Profile Page</tdef></dt>
@@ -408,8 +406,6 @@
 
 </section>
 
-<section>
-<h1>Preconditions</h1>
 
 <section class='normative'>
 <h1>The HTTP URI</h1>
@@ -418,6 +414,10 @@
 <p>For example, if a user Bob controls <code>https://bob.example/profile</code>,
 then his WebID can be <code>https://bob.example/profile#me</code>.</p>
 
+<p class="issue">Due to legacy support for URIs which do not contain URI fragment identifiers, verifiers MUST NOT fail when dereferencing hashless URIs, though they MAY flag them as potentially impacting on performance. Implementors need to take into account that the use of hashless URIs is deprecated and they must be avoided when creating new WebIDs.</p>
+
+</section>
+
 <section class='normative'>
 <h1>Publishing the WebID Profile Document</h1>
 
@@ -434,17 +434,6 @@
 
 <p class="issue">HTTP 303 redirects should be avoided (needs further discussion). Since WebIDs contain a URI fragment identifier, there is no longer necessary to use HTTP 303 redirects in order to make the difference between the identifier and the document it points to; the relationship becomes obvious.</p>
 
-<p class="issue">TODO: Irrespective of whether content negotiation can or cannot be employed, if an HTML representation of the WebID profile is published, it is suggested that the provider uses the HTML <code>&lt;link&gt;</code> element to allow discovery of the various alternate representations of the graph which may be available:
-</p>
-
-<pre class="example">
-&lt;html&gt;
-&lt;head&gt;
-&lt;link rel="alternate" type="text/turtle" href="profile.ttl"/&gt;
-&lt;link rel="alternate" type="application/rdf+xml" href="profile.rdf"/&gt;
-...
-&lt;/head&gt; ...
-</pre>
 <p>It is particularly useful to have one of the representations be in HTML
 even if it is not marked up in RDFa as this allows people using a
 web browser to understand what the information at that URI represents.</p>
@@ -452,7 +441,7 @@
 <section class='normative'>
 <h2>WebID Profile Vocabulary</h2>
 
-<p>RDF graphs are built using vocabularies defined by URIs, that can be placed in subject, predicate or object position.
+<p>WebID RDF graphs are built using vocabularies defined by URIs, that can be placed in subject, predicate or object position.
     The definition of each URI should be found at the namespace of the URI, by dereferencing it. 
 </p>
 
@@ -480,8 +469,8 @@
 <h1>Turtle</h1>
 <p>A widely used format for writing RDF graphs by hand is the <a href="http://www.w3.org/TR/turtle/">Turtle</a> [[!TURTLE-TR]] notation.
     It is easy to learn, and very handy for communicating over e-mail and on mailing lists.
-    The syntax is very similar to the SPARQL query language.
-    Turtle should be served with the <code>text/turtle</code> content type.
+    The syntax is very similar to the <a href="http://www.w3.org/TR/rdf-sparql-query/">SPARQL</a> query language.
+    Turtle profile documents should be served with the <code>text/turtle</code> content type.
 </p>
 <pre class="example" style="word-wrap: break-word; white-space: pre-wrap;">
  @prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
@@ -540,10 +529,6 @@
 &lt;/html&gt;
 </pre>
 </section>
-<section>
-<h1>In Portable Contacts format using GRDDL</h1>
-<p class="issue">TODO: discuss other formats and GRDDL, XSPARQL options for xml formats</p>
-</section>
 </section>
 
 <section class='normative'>
@@ -557,8 +542,6 @@
 </p>
 <p>If the <tref>Requesting Agent</tref> wishes to have the most up-to-date Profile document for an HTTPS URL, it can use the HTTP cache control headers to get the latest versions.</p>
 </section>
-</section>
-</section>
 
 <section class='appendix informative' id="history">
 <h1>Change History</h1>