spellchecked

diff --git a/org.glite.lb.doc/src/LBUG-Introduction.tex b/org.glite.lb.doc/src/LBUG-Introduction.tex
index 4ee69a7..f04cbfa 100644 (file)
--- a/org.glite.lb.doc/src/LBUG-Introduction.tex
+++ b/org.glite.lb.doc/src/LBUG-Introduction.tex
@@ -915,14 +915,14 @@ when RB decides where jobs get submitted.
 
 
 \subsubsection{CREAM jobs}
-\LB 2.2 implements support for CREAM jobs. \LB gathers events from CREAM, performing both the mapping of CREAM attributes to WMS attributes (if possible) and storing CREAM-specific atributes. Thus, the jobs submitted directly to computing elements can be tracked by \LB. Moreover, the jobs submitted to WMS and from there to CREAM logs WMS and CREAM data which are colligated by \LB providing more detailed and up-to-date job's data. The CREAM job states are mapped to \LB ones according to Appendix \ref{a:creammapping}.
+\LB 2.2 implements support for CREAM jobs. \LB gathers events from CREAM, performing both the mapping of CREAM attributes to WMS attributes (if possible) and storing CREAM-specific attributes. Thus, the jobs submitted directly to computing elements can be tracked by \LB. Moreover, the jobs submitted to WMS and from there to CREAM logs WMS and CREAM data which are integrated by \LB providing more detailed and up-to-date job's data. The CREAM job states are mapped to \LB ones according to Appendix \ref{a:creammapping}.
 
 CREAM events are generated by thee CREAM executor and LRMS, the generic \emph{CREAMStatus} event is generated when CREAM notifies that the job status has been changed.
 
 \subsubsection{Sandbox transfers}
 A sandbox transfer is special entity in \LB, which tracks the transfer of input or output sandboxes of the (compute) job. Thus, it allows to check state of sandboxes giving more detailed overview of the status of compute job.
 
-The sandbox transfer has its unique JobID and is cross-linked  with the related compute job. There are two types of sandboxes -- the input sandbox and the output sandbox. Each job has at most one input and one output sandbox associated, however, the sandbox can be created as a collection of sandboxes. The sandbox collection includes the owner, the overall status and the list of children sandboxes, whereas the regular sandbox tracks particular sandboc including data such as status, owner, source, destination. 
+The sandbox transfer has its unique JobID and is cross-linked  with the related compute job. There are two types of sandboxes -- the input sandbox and the output sandbox. Each job has at most one input and one output sandbox associated, however, the sandbox can be created as a collection of sandboxes. The sandbox collection includes the owner, the overall status and the list of children sandboxes, whereas the regular sandbox tracks particular sandbox including data such as status, owner, source, destination. 
 
 Having its unique JobID, sandbox transfers are  tracked by standard tools (API, command line utilities, HTTPs, notifications) in the same manner as traditional compute jobs.