[ogf nmc-base svn commit] r12 - /
Author: zurawski Date: 2010-01-28 08:03:50 -0600 (Thu, 28 Jan 2010) New Revision: 12 Modified: extension.tex messages.tex nmc-base.pdf Log: Correcting errors and adding comments from Slawek. -jason Modified: extension.tex =================================================================== --- extension.tex 2010-01-28 13:53:49 UTC (rev 11) +++ extension.tex 2010-01-28 14:03:50 UTC (rev 12) @@ -209,7 +209,7 @@ \paragraph{Response Message Schema} \label{s:echo_protocol_response_schema} -The following schema is a native description of the request schema as in the RELAX-NG\cite{relaxng} language. Through the use of tools such as Trang\cite{trang} and MSV\cite{msv} it is possible to convert this to other widely accepted formats such as XSD\cite{xsd}. The following describes the \textbf{EchoRequest} schema. Note that this will only validate \textbf{EchoRequest} messages. +The following schema is a native description of the response schema as in the RELAX-NG\cite{relaxng} language. Through the use of tools such as Trang\cite{trang} and MSV\cite{msv} it is possible to convert this to other widely accepted formats such as XSD\cite{xsd}. The following describes the \textbf{EchoResponse} schema. Note that this will only validate \textbf{EchoResponse} messages. \tiny \begin{verbatim} @@ -403,6 +403,14 @@ \paragraph{Response Message Example} \label{s:echo_protocol_response_example} + +% XXX jz - 1/28/2010 +% +% A comment from Slawek: +% +% Fix the examples to use new result codes. +% + The first example shows a correct configuration for an \textbf{EchoResponse} message. \tiny Modified: messages.tex =================================================================== --- messages.tex 2010-01-28 13:53:49 UTC (rev 11) +++ messages.tex 2010-01-28 14:03:50 UTC (rev 12) @@ -46,7 +46,7 @@ \begin{itemize} \item \textbf{Message Type} - Every \textit{message} \textbf{MUST} contain a \textit{type}, these facilitate the semantic intentions of the internal data -\item \textbf{Message Structure} - There\textbf{MAY} be \textit{metadata} and/or \textit{data} elements in each message, and there \textbf{MAY NOT} need to be a matching data for every metadata (e.g. \textit{Chaining}, see Section~\ref{s:information_chaining}) +\item \textbf{Message Structure} - There \textbf{MAY} be \textit{metadata} and/or \textit{data} elements in each message, and there \textbf{MAY NOT} need to be a matching data for every metadata (e.g. \textit{Chaining}, see Section~\ref{s:information_chaining}) \item \textbf{Metadata} - \textbf{SHOULD} contain measurement data, identifying information about a service, or even information meant to serve as a modifier (see see Section~\ref{s:information_chaining}). Note that we still loosely observe the static rule of thumb \item \textbf{Data} - Serves a dual role: in request messages this \textbf{MAY} be empty (e.g. this is a \textit{data trigger}, it lets the service know we need action on the accompanying metadata), or it \textbf{MAY} contain dynamic measurement data or even other metadata elements \end{itemize} Modified: nmc-base.pdf =================================================================== (Binary files differ)
participants (1)
-
svn@ogf.org