Removed obsolete terminilogy items.
authorAndrei Sambra <andrei@fcns.eu>
Sun, 18 Nov 2012 21:20:09 -0500
changeset 290 2bb917261ef7
parent 289 ab6c8dd292d3
child 291 427afd1d488b
Removed obsolete terminilogy items.
spec/identity-respec.html
--- a/spec/identity-respec.html	Sun Nov 18 18:07:23 2012 -0500
+++ b/spec/identity-respec.html	Sun Nov 18 21:20:09 2012 -0500
@@ -363,16 +363,6 @@
 <section>
 <h1>Terminology</h1>
 <dl>
-<dt><tdef>Alice</tdef></dt>
-<dd>Alice is an agent who owns a Server which runs a Service which Bob wishes to Access.</dd>
-
-<dt><tdef>Bob</tdef></dt>
-<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service.</dd>
-<dt><tdef>Subject</tdef></dt>
-<dd>The Subject is the Agent that is identified by the <tref>WebID</tref>.
-We will name him <tref>Bob</tref> throughout this document to improve readability.
-The Subject is distinct from the <tref>Client</tref> which is used to connect to the <tref>Server</tref>.
-</dd>
 <dt><tdef>Requesting Agent</tdef></dt>
 <dd>The Requesting Agent initiates a request to a Service listening on a specific port using a given protocol on a given Server.</dd>
 
@@ -426,19 +416,19 @@
 
 <p>This URI must be one that dereferences to a document the user controls.</p>
 <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>
+then his WebID can be <code>https://bob.example/profile#me</code>.</p>
 
 <section class='normative'>
 <h1>Publishing the WebID Profile Document</h1>
 
 <p>The set of relations to be published in the <tref>WebID Profile</tref> document can be presented in a graphical notation as follows.</p>
 <img alt="WebID overview" width="90%" src="img/WebID-overview.png"/>
-<p>The document can publish many more relations than are of interest to the WebID protocol, as shown in the above graph. 
-For example Bob can publish a depiction or logo, so that sites he authenticates to can personalize the user experience. He can post links to people he knows, where those have WebIDs published on other sites, in order to create a distributed Social Web. 
+<p>The document can publish many more relations than are of interest to the WebID profile, as shown in the above graph. 
+For example Bob can publish a depiction or logo, so that sites he authenticates to can personalize the user experience. He can post links to people he knows, who in turn have WebIDs published on other sites, in order to create a distributed Social Web. 
 He can also publish one or more authentication principals. More information on authentication principals can be found on the <a href="http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability">WebID Identity Interoperability</a> page.
 </p>
 <p>
-The protocol does not depend on any particular serialization of the graph, provided that agents are able to parse that serialization and obtain the graph automatically.  
+WebID requires that servers MUST at least be able to provide Turtle representation of profile documents, but other serialization formats of the graph are allowed, provided that agents are able to parse that serialization and obtain the graph automatically.  
 Technologies such as GRDDL [[!GRDDL-PRIMER]] for example permit any XML format to be transformed automatically to a graph of relations.
 HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serializations of the same graph at the same URL, as explained by the working group note <a href="http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/">Best Practice Recipes for Publishing RDF Vocabularies</a> [[!SWBP-VOCAB-PUB]]</p>
 
@@ -563,7 +553,7 @@
 The Agent requesting the WebID document MUST be able to parse documents in Turtle [[!TURTLE-TR]], but MAY also be able to parse documents in RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-CORE]].
 The result of this processing should be a graph of RDF relations that is queryable, as explained in the next section.</p>
 <p class="note">
-It is suggested that the <tref>Requesting Agent</tref> should set the Accept-Header to request <code>text/turtle</code> with a higher priority than <code>application/xhtml+xml</code>(RDFa) and <code>application/rdf+xml</code> (RDF/XML). The reason is that it is quite likely that many sites will produce non marked up HTML and leave the graph to the pure rdf formats.
+It is important that the <tref>Requesting Agent</tref> should set the Accept-Header to request <code>text/turtle</code> with a higher priority than <code>application/xhtml+xml</code>(RDFa) and <code>application/rdf+xml</code> (RDF/XML). The reason is that it is quite likely that many sites will produce non marked up HTML and leave the graph in pure RDF formats.
 </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>
@@ -607,9 +597,9 @@
 <h1>Acknowledgments</h1>
 
 <p>The following people have been instrumental in providing thoughts, feedback,
-reviews, criticism and input in the creation of this specification:
-
-Tim Berners-Lee, Melvin Carvalho, Kingsley Idehen, Nathan Rixham, Ted Thibodeau, Alexandre Bertails, Olivier Berger, Sebastian Trüg.
+reviews, criticism and input in the creation of this specification:</p>
+<p>Tim Berners-Lee, Melvin Carvalho, Kingsley Idehen, Nathan Rixham, Ted Thibodeau,
+ Alexandre Bertails, Olivier Berger, Sebastian Trüg.</p>
 
 </section>
   </body>