-\subsection{\glspl{SDS}}
-\Glspl{SDS} on a client are available on the server as well. However, the same
-freedom is not given on the \glspl{SDS} that reside on the client. Not all
-types are suitable to be located on a client. Moreover, \glspl{SDS} behave a
-little bit differently on an \gls{mTask} device than in the \gls{iTasks}
-system. In an \gls{iTasks} system, when the \gls{SDS} is updated, a broadcast
-to everyone in the system watching is made to notify them of an update.
-\glspl{SDS} on the device can update very often and the update might not be the
-final value it will get. Therefore a device must publish the \gls{SDS}
+\section{\gls{SDS} semantics}
+\Glspl{SDS} on a client are available on the server as well as regular
+\glspl{SDS}. However, the same freedom is not given for \glspl{SDS} that
+reside on the client. Not all types are suitable to be located on a client,
+simply because it needs to be serializable and representable on clients.
+Moreover, \glspl{SDS} behave a little different in an \gls{mTask} device
+compared to in the \gls{iTasks} system. In an \gls{iTasks} system, when the
+\gls{SDS} is updated, a broadcast to all watching \glspl{Task} in the system
+is made to notify them of the update. \glspl{SDS} can update often and the
+update might not be the final value it will get. Implementing the same
+functionality on the \gls{mTask} client would result in a lot of expensive
+unneeded bandwidth usage. Therefore a device must publish the \gls{SDS}