2009/dap/design-patterns Overview.html,1.1,1.2

Update of /sources/public/2009/dap/design-patterns
In directory hutz:/tmp/cvs-serv24400

Modified Files:
	Overview.html 
Log Message:
obsolete

Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/design-patterns/Overview.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- Overview.html	2 Nov 2009 09:38:43 -0000	1.1
+++ Overview.html	5 Jul 2011 14:06:36 -0000	1.2
@@ -16,67 +16,11 @@
     </script>
     <script src='../common/configPolicy.js' class='remove'></script>
   </head>
-<body>
+  <body>
     <section id='abstract'>
-      These are the requirements for the API Design Patterns work undertaken by the
-      DAP WG.
-    </section>
-    
-    <section class='informative'>
-      <h2>Introduction</h2>
-      <p>
-        This document is an editors' draft and currently does not
-        reflect consensus of the WG but rather is a starting point for
-        further work. It is based on input documents and list
-        discussion.
-      </p>
-    </section>
-
-    <section>
-		<h2>Design Patterns</h2>
-		<section>
-			<h3>Requirements</h3>
-			<p>
-			At present the below items list both patterns and naming conventions.
-			</p>
-			<ul>
-				<li>Naming of WebIDL modules, interfaces, attributes and methods MUST follow the camelCase form.
-				</li>
-				<li>WebIDL constant defined by DAP APIs MUST be capitalized.
-				</li>
-				<li>There MUST be a common pattern
-				</li>
-				<li>All APIs MUST follow the same convention when handling callback functions
-				(e.g. XHR / FileAPI style with onreadystatechange, or ProgressEvent with EventTarget).
-				</li>
-				<h3>Issues</h3>
-				<p class="issue">
-				Maybe it would be possible to define the API in such an abstract way that both models: XHR and ProgressEvent could handle the architecture
-				and vendors could differentiate?
-				</p>
-				<li>Large data collections MUST be handled uniformly through all the APIs.
-				</li>
-				<li>There MUST be a common pattern for handling asynchronous operations (e.g. through events, callbacks or mixed)
-				</li>
-				<li>There MUST be a host object representing the asynchronous operation.
-				</li>
-				<li>The asynchronous operation MUST be cancellable with a commonly defined operation on the asynchronous object.
-				</li>
-				<li>There MUST be a common pattern for handling the information passed by the host objects (e.g. events, callbacks, mixed events and callbacks).
-				</li>
-				<li>There MUST be a common naming scheme for the methods handling basic record manipulation operations (e.g. "Create" for record/item creation, "Delete" for destruction,
-				"Update" or "Save" for updating, "Read" or direct object retrieval for access to the properties, "Remove" for removal from the collection [no destruction]).
-				</li>
-			</ul>
-		</section>
+      This is an obsolete document that was never formally accepted by the DAP WG and on which work has been discontinued.
+      Previous content is available in CVS. Please do not refer to this document in any way other than as a proposed
+      work item now abandoned.
     </section>
-
-	<section class='appendix'>
-		<h2>Acknowledgements</h2>
-		<p>
-			The editors would like to extend special thanks to ACCESS Co., Ltd., OMTP
-			BONDI and Nokia for providing the foundation of the working group's requirements discussion.
-		</p>
-	</section>
-</body>
+  </body>
 </html>

Received on Tuesday, 5 July 2011 14:06:40 UTC