svn commit: r154993 - in webservices/axis/trunk/java: maven.xml xdocs/OMTutorial.html xdocs/docs.html

[ch...@apache.org]

Author: chinthaka
Date: Wed Feb 23 01:57:35 2005
New Revision: 154993

URL: http://svn.apache.org/viewcvs?view=rev&rev=154993
Log: (empty)


Modified:
    webservices/axis/trunk/java/maven.xml
    webservices/axis/trunk/java/xdocs/OMTutorial.html
    webservices/axis/trunk/java/xdocs/docs.html

Modified: webservices/axis/trunk/java/maven.xml
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/maven.xml?view=diff&r1=154992&r2=154993
==============================================================================
--- webservices/axis/trunk/java/maven.xml (original)
+++ webservices/axis/trunk/java/maven.xml Wed Feb 23 01:57:35 2005
@@ -228,7 +228,7 @@
     <attainGoal name="dist-bin"/>
     <attainGoal name="war"/>
     <attainGoal name="javadoc-gen"/>
-    <attainGoal name="pdf"/>
+    <!-- attainGoal name="pdf"/ -->
     <copy todir="target/docs/api">
 		<fileset dir="target/apidocs" />
 	</copy>
@@ -236,8 +236,8 @@
 	<copy file="target/axis2-src-M1.zip" tofile="target/docs/dist/axis2-src-M1.zip"/>
 	<copy file="target/axis2-bin-M1.zip" tofile="target/docs/dist/axis2-bin-M1.zip"/>
 	<copy file="target/axis2.war" tofile="target/docs/dist/axis2.war"/>
-	<copy file="target/pdf/axis2.pdf" tofile="target/docs/axis2.pdf"/>
-	<ant:delete dir="target/pdf"/>
+	<!-- copy file="target/pdf/axis2.pdf" tofile="target/docs/axis2.pdf"/>
+	<ant:delete dir="target/pdf"/ -->
   </preGoal>
   </project>
 

Modified: webservices/axis/trunk/java/xdocs/OMTutorial.html
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/OMTutorial.html?view=diff&r1=154992&r2=154993
==============================================================================
--- webservices/axis/trunk/java/xdocs/OMTutorial.html (original)
+++ webservices/axis/trunk/java/xdocs/OMTutorial.html Wed Feb 23 01:57:35 2005
@@ -98,7 +98,7 @@
 <p>After the source download OM-binary can be built. 
 For both Windows and Linux move to the project directory and execute the command "maven jar". All other necessary jars will be automatically downloaded.
 When the build finishes successfully, the axis2-om-M1.jar can be found in the newly created "targets" directory</p>
-<p>Once the Om-binary is obtained by any of the mentioned means,it should be included in the class path for any of the OM based programs to work. The subsequent parts of this tutorial assume that this build step is complete and the Axis-M1.jar is correctly in the classpath along with the StAX API jar file and a StAX implementation.
+<p>Once the OM-binary is obtained by any of the mentioned means,it should be included in the class path for any of the OM based programs to work. The subsequent parts of this tutorial assume that this build step is complete and the Axis-M1.jar is correctly in the classpath along with the StAX API jar file and a StAX implementation.
 </p><h3>Creation</h3>
 <p>Creation is the first and foremost action in using an Object representation. This part explains how OM can be built from an existing document or just programmatically.
 OM provides a notion of a factory and a builder to create objects. The factory helps to keep the code at the interface level and the implementations separately (Figure 2). Since OM is tightly bound to StAX, a StAX compliant reader should be created first with the desired input stream. Then the reader should be fed into the OMXMLBuilderFactory to instantiate a suitable builder.
@@ -139,7 +139,7 @@
 <div align="left"><b>Code listing 2.2</b></div>
 <p>The reason to have a set of factory.createXXX methods is to cater for different implementations but keep the programmers code intact. Its highly recommend to use the factory for creating OM objects as this will ease the switching of different OM implementations.
 Several differences exist between a programmatically created OMNode and a conventionally built OMNode. The most important difference is that the former will have no builder object enclosed where as the latter always carries a reference to its builder. As stated earlier in this tutorial, since the object model is built as and when required, each and every OMNode should have a reference to its builder. If this information is not available, it is due to the Object being created without a builder.  In other words programmatically built OMNodes do not have a reference to a builder. This difference becomes evident when the user tries to get a non caching pull parser from the OMElement. This will be discussed in more detail in the advanced operations section.
-In order to understand the requirement of the builder reference in each and every OMNode, consider the following scenario. Assume that the parent element is built but the children elements are not. If the parent is asked to iterate through its children, this information is not readily available to the parent element and it should build its children first before attempting to iterate them. In order to provide a reference of the builder, each and every node of an OM structure should carry the reference to its builder. Each and every OmNode carries a flag that states its build status.
+In order to understand the requirement of the builder reference in each and every OMNode, consider the following scenario. Assume that the parent element is built but the children elements are not. If the parent is asked to iterate through its children, this information is not readily available to the parent element and it should build its children first before attempting to iterate them. In order to provide a reference of the builder, each and every node of an OM structure should carry the reference to its builder. Each and every OMNode carries a flag that states its build status.
 Apart from this restriction there are no other constraints that keep the programmer away from mixing up programmatically made OMNode objects with OMNode objects built from builders.</p>
 
 <p>The SOAP Object hierarchy is made in the most natural way for a programmer. An inspection of the API will show that it is quite close to the SAAJ API but with no bindings to DOM or any other model. The SOAP classes extend basic OM classes (such as the element) hence one can access a SOAP document either with the abstraction of SOAP or drill down to the underlying XML Object model with a simple casting.</p>
@@ -242,7 +242,7 @@
 <p>OM can be serialized either as the pure object model or the pull event stream. The serialization uses a XMLStreamWriter object to write out the output and hence the same serialization mechanism can be used to write different types of outputs (such as text, binary, etc.,).</p>
 <p>A caching flag is provided by OM to control the building of the in-memory OM.
 The OMNode has a method serialize(XMLStreamWriter,cache).  When the cache flag is reset the serializer does not cache the stream. Hence the object model will not be built if the cache flag is not set. </p>
-<p>The serializer serializes namespaces the following way.</p>
+<p>The serializer serializes namespaces in the following way.</p>
 <ol>
 <li>When a namespace that is in the scope but not yet declared is encountered, then it will be declared.</li>
 <li>When a namespace that is in scope and already declared is encountered, the existing declarations prefix is used.</li>

Modified: webservices/axis/trunk/java/xdocs/docs.html
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/docs.html?view=diff&r1=154992&r2=154993
==============================================================================
--- webservices/axis/trunk/java/xdocs/docs.html (original)
+++ webservices/axis/trunk/java/xdocs/docs.html Wed Feb 23 01:57:35 2005
@@ -19,10 +19,10 @@
 		Client API</a> </li>
 		<li><a href="refLib.html">Reference 
 		Material</a> </li>
-	</ul>
+    </ul>
   <div class="h4">
 		<h4>Documentation for Axis Developers</h4>
-	</div>
+  </div>
 	<ul><li><a href="Axis2ArchitectureGuide.html">
 		Architecture Guide</a> - Axis design concepts and rationale.</li>
 		<li><a href="svn.html">Setting up the project</a>- Instruction to set up