[MOBY-guts] biomoby commit

[Mark Wilkinson]

mwilkinson
Mon Nov 20 21:41:45 EST 2006
Update of /home/repository/moby/moby-live/Docs/MOBY-S_API
In directory dev.open-bio.org:/tmp/cvs-serv13021

Modified Files:
	DataClassOntology.html InputMessage.html ObjectStructure.html 
Log Message:
fixed some of the documentation, where the links for an invocation message structure were mixed up with the links for a registry call
moby-live/Docs/MOBY-S_API DataClassOntology.html,1.5,1.6 InputMessage.html,1.6,1.7 ObjectStructure.html,1.6,1.7
===================================================================
RCS file: /home/repository/moby/moby-live/Docs/MOBY-S_API/DataClassOntology.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- /home/repository/moby/moby-live/Docs/MOBY-S_API/DataClassOntology.html	2006/02/10 17:48:25	1.5
+++ /home/repository/moby/moby-live/Docs/MOBY-S_API/DataClassOntology.html	2006/11/21 02:41:45	1.6
@@ -110,7 +110,7 @@
 <p>
 Notice, these primitive types are the only cases where the content
 of the element is meant to be interpreted by the client or service.
-New classes <em>may not</em> inherit from the Primitive Classes.  To obtain
+New classes <em>MUST NOT</em> inherit from the Primitive Classes.  To obtain
 content in another class, you must be a <em>container</em> of a
 primitive class. The two relationship types - HASA and HAS - are used
 to indicate container relationships, and the contained object is

===================================================================
RCS file: /home/repository/moby/moby-live/Docs/MOBY-S_API/InputMessage.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- /home/repository/moby/moby-live/Docs/MOBY-S_API/InputMessage.html	2006/09/22 22:25:55	1.6
+++ /home/repository/moby/moby-live/Docs/MOBY-S_API/InputMessage.html	2006/11/21 02:41:45	1.7
@@ -88,10 +88,10 @@
 The <code>mobyData</code> tags delimit the set of inputs to a <em>single
 invocation</em> of the service, though there may be multiple
 invocations in a single message, each contained within its own
-enumerated <code>mobyData</code> block. The contents of this block may be a <a
-href="PrimaryMessage.html">Primary article</a> (<a
+enumerated <code>mobyData</code> block. The contents of this block may be a Primary
+article </a> (<a
 href="#SimpleExample">Simple</a>, or <a href="#CollectionExample">Collection</a>), 
-or a <a href="SecondaryArticle.html">Secondary article</a> (e.g., a <a href="#ParameterExample">Parameter</a>).</p>
+or a <a href="#ParameterExample">Secondary</a> article, which are Parameters used to modify the service behaviour.</p>
 
 <p/>
 Any request sent to a service with no <code>mobyData</code> blocks

===================================================================
RCS file: /home/repository/moby/moby-live/Docs/MOBY-S_API/ObjectStructure.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- /home/repository/moby/moby-live/Docs/MOBY-S_API/ObjectStructure.html	2006/02/10 16:37:09	1.6
+++ /home/repository/moby/moby-live/Docs/MOBY-S_API/ObjectStructure.html	2006/11/21 02:41:45	1.7
@@ -65,7 +65,16 @@
 It is our intention that MOBY Objects should be as lightweight as
 possible.  This not only reduces bandwith, speeds up service response
 time, and reduces server load, it also reduces conflict that arises
-from disagreement over the structure of more complex objects.
+from disagreement over the structure of more complex objects.  More importantly, however, it results in
+ the creation of Services that have near-transparent semantics.  Because of the limited
+ Service Ontology, the functionality of BioMoby services must be clearly
+ described in a single word.  Generally speaking, if an Object contains
+ "lots of information", the Service that generates it will be quite complex.
+ Complex services cannot be described in the BioMoby system.  As such, BioMoby
+ services attempt to be highly modular - complex data is derived by accessing
+ a broader arrange of lightweight services and integrating this data client-side,
+ in contrast to accessing a "one service provides all" Service whose output consists of many
+ data-types.
 </p>
 
 MOBY Object structure is inferred by looking up the Object Class in
@@ -133,11 +142,11 @@
 <a name="ObjectValue"></a>
 The content of the Object element is ignored <strong><em>with the
 exception of</em></strong> the Classes representing primitives
-(e.g. Integer, Float, String, etc.; discussed in the <a
+(e.g. Integer, Float, String, etc.; discussed in the Special Case Primitives section of the <a
 href="DataClassOntology.html">Class
-Ontology</a> section below).  For example, in the following object
+Ontology</a>).  For example, in the following object
 <pre class=MOBYcode>
-           &lt;Object namespace="NCBI_gi" moby:id="163483" &gt; this value is ignored &lt;/Object&gt;
+           &lt;moby:Object namespace="NCBI_gi" moby:id="163483" &gt; this value is ignored &lt;/Object&gt;
 </pre>
 the text "this value is ignored" is ignored by both client and service.
 </p>