Mock up new section for rules declared to be non-normative restatements of info from other specs
authorJohn Arwe
Tue, 01 Oct 2013 16:12:23 -0400
changeset 374eeff2a51723d
parent 373 0562f8c4d4d4
child 375 414ee07c3714
Mock up new section for rules declared to be non-normative restatements of info from other specs
ldp.html
     1.1 --- a/ldp.html	Tue Oct 01 14:50:16 2013 -0400
     1.2 +++ b/ldp.html	Tue Oct 01 16:12:23 2013 -0400
     1.3 @@ -1733,6 +1733,112 @@
     1.4  </div>
     1.5  </section> <!-- Client constraints -->
     1.6  
     1.7 +<section id="base-specs" class="informative">
     1.8 +<h1>Notable information from normative references</h1>
     1.9 +<div class="ldp-issue-open">
    1.10 +
    1.11 +<p>
    1.12 +AT THIS POINT ALL TEXT HAS BEEN COPIED HERE, NOT MOVED.
    1.13 +DEPENDING UPON HOW THE WG ALTERS THE PROPOSAL BASED ON FEEDBACK, IT MIGHT CHANGE.
    1.14 +THE 2119 LANGUAGE NEEDS TO BE REMOVED TOO.
    1.15 +Given that it's from base specs => important to understand, should be moved up before 
    1.16 +most of the normative sections IMO - renumbering hit again.
    1.17 +</p>
    1.18 +
    1.19 +<p>
    1.20 +While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
    1.21 +references, the working group has found that certain points are particularly important to understand.
    1.22 +For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
    1.23 +experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
    1.24 +it is simply re-stating (informatively) information locatable via the normative references.
    1.25 +</p>
    1.26 +
    1.27 +<section id="specs-webarch" class="informative">
    1.28 +<h1>Architecture of the World Wide Web</h1>
    1.29 +Reference: [[WEBARCH]]
    1.30 +
    1.31 +	<div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
    1.32 +	(LDPR or not) MAY be a member of more than one LDPC.
    1.33 +	</div>
    1.34 +	<div id="ldpc-5_2_9" class="rule">5.2.9 <a title="LDP server">LDP servers</a> SHOULD NOT re-use URIs, 
    1.35 +		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
    1.36 +		Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
    1.37 +		URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
    1.38 +		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
    1.39 +		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
    1.40 +	</div>
    1.41 +
    1.42 +</section> 
    1.43 +
    1.44 +<section id="specs-http" class="informative">
    1.45 +<h1>HTTP 1.1</h1>
    1.46 +Reference: [[HTTP11]]
    1.47 +
    1.48 +	<div id="ldpr-4_2_6" class="rule">4.2.6 <a title="LDP server">LDP servers</a> MAY support standard representations beyond those
    1.49 +		necessary to conform to this specification. These
    1.50 +		could be other RDF formats, like N3 or NTriples, but non-RDF formats
    1.51 +		like HTML [[!HTML401]] and JSON [[!RFC4627]] would likely be common.
    1.52 +	</div>		
    1.53 +	<div id="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
    1.54 +		this document, for example through application-specific means, SPARQL
    1.55 +		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
    1.56 +		normative requirements.
    1.57 +	</div>
    1.58 +	<div id="ldpr-4_3_4" class="rule">4.3.4 <a title="LDP server">LDP servers</a> MAY provide 
    1.59 +		representations of the requested LDPR beyond those
    1.60 +		necessary to conform to this specification, using standard HTTP content negotiation ([[!HTTP11]] Section 12 - Content Negotiation). 
    1.61 +	</div>
    1.62 +	<div id="ldpr-4_6_1" class="rule">4.6.1 <a title="LDP server">LDP servers</a> MUST remove the resource identified by the <code>Request-URI</code>.
    1.63 +		After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
    1.64 +		<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
    1.65 +		code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
    1.66 +	</div>
    1.67 +	
    1.68 +	<div id="ldpr-4_6_2" class="rule">4.6.2 <a title="LDP server">LDP servers</a> MAY alter the state of other resources as a result of an
    1.69 +		HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
    1.70 +		remove triples from other resources whose subject or object is the
    1.71 +		deleted resource. It is also acceptable and common for <a title="LDP server">LDP servers</a> to
    1.72 +		not do this – behavior is server application specific.
    1.73 +	</div>
    1.74 +	<div id="ldpr-4_8_1" class="rule">4.8.1 <a title="LDP server">LDP servers</a> MAY implement HTTP <code>PATCH</code> to allow modifications,
    1.75 +		especially partial replacement, of their resources [[!RFC5789]]. No
    1.76 +		minimal set of patch document formats is mandated by this document.
    1.77 +	</div>
    1.78 +	<div id="ldpc-5_4_2" class="rule">5.4.2 ... An LDPC MAY also contain resources that were
    1.79 +		added through other means ... stays normative, sept 25 email
    1.80 +	</div>
    1.81 +	<div id="ldpc-5_4_6" class="rule">5.4.6 ...  When the header is absent, 
    1.82 +		<a title="LDP server">LDP servers</a> MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
    1.83 +	</div>
    1.84 +	<div id="ldpc-5_4_10" class="rule">5.4.10 ... stays normative, sept 25 email
    1.85 +	</div>
    1.86 +
    1.87 +</section> 
    1.88 +
    1.89 +<section id="specs-rdf" class="informative">
    1.90 +<h1>RDF</h1>
    1.91 +Reference: [[RDF-CONCEPTS]]
    1.92 +
    1.93 +	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
    1.94 +		additional triples whose subjects are the members of the container,
    1.95 +		or that are from the representations of the members (if they have RDF
    1.96 +		representations). This allows a LDPC server to provide clients with
    1.97 +		information about the members without the client having to do a <code>GET</code>
    1.98 +		on each member individually.  See <a href="#ldpc-member_data">section 5.1.1 Container
    1.99 +		Member Information</a> for additional details.
   1.100 +    </div>
   1.101 +	<div id="ldpc-5_2_7" class="rule">5.2.7  , but it [The representation of a LDPC] MAY have additional
   1.102 +		<code>rdf:type</code>s.
   1.103 +	</div>
   1.104 +	<div id="ldpc-5_3_1" class="rule">5.3.1 ... stays normative, sept 25 email
   1.105 +	</div>
   1.106 +
   1.107 +</section> 
   1.108 +
   1.109 +
   1.110 +</div>
   1.111 +</section> <!-- Base specs -->
   1.112 +
   1.113  
   1.114  <section class='appendix informative'>
   1.115  <h2>Acknowledgements</h2>
   1.116 @@ -1758,9 +1864,10 @@
   1.117  
   1.118  <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote>  -->
   1.119  <ul>
   1.120 +    <li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
   1.121      <li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
   1.122      <li>2013-10-01 - Revising introduction (JA)</li>
   1.123 -    <li>2013-10-01 - Conformance section drafting (JA)</li>
   1.124 +    <li>2013-10-01 - Conformance section drafting + mock up "LDP Clients" section as part of that (JA)</li>
   1.125      <li>2013-09-23 - Remove client/server-initiated paging terms (JA)</li>
   1.126      <li>2013-09-17 - Change must to MUST in <a href="#ldpc-5_6_4">5.6.4</a> (SS)</li>
   1.127  	<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>