Notable statements of legacy requirements highlighted as input for di…

…scussion

ucr/index.html

@@ -3318,18 +3318,19 @@ <h3>Publication control [RPC]</h3>
 <h2>Profile</h2>
     <section class="requirement" id="RPFDF">
     <h3>Profile definition [RPFDF]</h3>
+    <div class="note">This composite requirement is subject to deduplication and deletion</div>    
     <p>Create a sufficiently wide definition of an application profile to address declaration of interoperability profiles data
       		may conform to, and through this mechanism provide the means for DCAT instances and collections to also declare the
-		 profiles of DCAT they conform to.</p>
+		 profiles of DCAT they conform to.</p>         
 		 <p class="note">These Use case specific requirements apply to the required scope of this definition. Where
 		      appropriate these are also captured as additional requirements.
 			<ol>
 				<li>Clarify any relationship between profiles and validation languages</li>
 				<li>Profiles have URI identifiers that resolve to more detailed descriptions</li>		
 				<li>Each application profile needs to be documented, preferably by showing/reusing what is common across profiles</li>
-				<li>Profiles should provide both machine and human readable views.</li>
+				<li>Profiles <b>should provide both</b> machine and human readable views.</li>
 				<li>Profiles may inherit clauses from one or more parent profiles <!--(see <a href="#extensibility">below</a>)--></li>
-				<li>Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in.</li>
+				<li><b>Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in.</b></li>
 				<li>Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to.</li>
 				<li><!--<a name="extensibility"></a>-->Conceptually, profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles <a href="#ID37"></a></li>
 				<li>Responses can conform to multiple, modular profiles <a href="#ID3"></a></li>
@@ -3352,6 +3353,7 @@ <h3>Profile definition [RPFDF]</h3>
 
   <section class="requirement" id="RPFRP">
     <h3>Profile representation [RPFRP]</h3>
+    <div class="note">This composite requirement is subject to deduplication and deletion</div>    
     <p>Create a way to retrieve more information about a profile.
      This must be flexible enough to support human and machine readable resources,
      such as input and editing guidance, validation resources, usage notes etc.</p>
@@ -3362,13 +3364,13 @@ <h3>Profile representation [RPFRP]</h3>
 		<li>Application profiles need a rich expression for the validation of metadata</li>
 		<li>Profiles must have properties for at least two levels of documentation: 1) short definition 2) input and editing guidance</li>
 		<li>Profiles must support declaration of vocabulary constraints</li>
-		<li>A mechanism must be available to identify conformance to each inherited profile given conformance to a profile that specialises it.</li>
+		<li><b>A mechanism must be available to identify conformance to each inherited profile given conformance to a profile that specialises it.</b></li>
 		<li>Profiles list valid vocabulary terms for a metadata usage environment</li>
-		<li>Profile vocabulary lists may be defined as closed (no other terms are allowed) or open (other terms are allowed) <a href="#ID37"></a></li>
+		<li>Profile vocabulary lists may be defined as <b>closed (no other terms are allowed) or open (other terms are allowed)</b> <a href="#ID37"></a></li>
 		<li>Profiles should reuse vocabulary terms defined elsewhere (Dublin Core profiles; no use case)</li>
 		<li>Profiles must be able to support information that can drive data creation functions, including brief and detailed documentation <a href="#ID46"></a></li>
 		<li>Profiles must support discoverability via search engines <a href="#ID40"></a></li>
-		<li>Profiles must have identifiers that can be used to link the DCAT description to the relevant profile</li>
+		<li>Profiles must have identifiers that can be used to <b>link the DCAT description to the relevant profile</b></li>
 	</ol>
 	 <p class="relatedRequirements">
       <a href="#RPFDF"></a>
@@ -3383,6 +3385,7 @@ <h3>Profile representation [RPFRP]</h3>
 
   <section class="requirement" id="RPFN">
     <h3>Profile negotiation [RPFN]</h3>
+    <div class="note">This legacy requirement is subject to deletion</div>
     <p>Create a way to negotiate choice of profile between clients and servers</p>
     <p class="relatedRequirements">
       <a href="#RPFDF"></a>
@@ -3395,6 +3398,7 @@ <h3>Profile negotiation [RPFN]</h3>
 
   <section class="requirement" id="RPFL">
     <h3>Profiles listing [RPFL]</h3>
+    <div class="note">This legacy requirement is subject to deletion</div>
     <p>Create a way to list the profiles implemented by a dataset or a specific distribution</p>
 		      <p class="note">Some subset of profile metadata that can be included in a DCAT context should have a canonical set of properties recommended. Initial requirements are 1) short definition 2) input and editing guidance. Links should be consistent with <a href="#RPFRP"></a></p>
 
@@ -3425,26 +3429,26 @@ <h3>Profile identifier [RPFID]</h3>
     <span class="source"><a target="_blank" rel="nofollow" class="external free" href="https://github.com/w3c/dxwg/issues/284">github:issue/284</a></span>
   </section>
 
-  <section class="requirement" id="RPFSSS">
-    <h3>Server-side profile support [RPFSSS]</h3>
+  <section class="requirement" id="RPFSUP">
+    <h3>Server-side profile support [RPFSUP]</h3>
     <p>A client should be able to determine which profiles are supported by a server, and with which content types or other properties, in order to receive the one most appropriate for their use.</p>
     <p class="relatedUseCases">
       <a href="#ID2"></a>	  
     </p>
     <span class="source"><a target="_blank" rel="nofollow" class="external free" href="https://github.com/w3c/dxwg/issues/285">github:issue/285</a></span>
   </section>
 
-  <section class="requirement" id="RPFLPD">
-    <h3>Lookup of profile details [RPFLPD]</h3>
+  <section class="requirement" id="RPFLUP">
+    <h3>Lookup of profile details [RPFLUP]</h3>
     <p>There should be a way to look up additional information about a profile - this may be machine readable for run-time mediation or used to develop or configure a client.</p>
     <p class="relatedUseCases">
       <a href="#ID2"></a>	  
     </p>
     <span class="source"><a target="_blank" rel="nofollow" class="external free" href="https://github.com/w3c/dxwg/issues/286">github:issue/286</a></span>
   </section>
 
-  <section class="requirement" id="RPFRCMP">
-    <h3>Response conformance to multiple profiles [RPFRCMP]</h3>
+  <section class="requirement" id="RPFRCONF">
+    <h3>Response conformance to multiple profiles [RPFRCONF]</h3>
     <p>Some data may conform to one or more profiles at once. A server can indicate that a response conforms to multiple profiles.</p>
     <p class="relatedUseCases">
       <a href="#ID3"></a>