[Nmc-wg] [ogf nmc-base svn commit] r12 - /

svn at ogf.org svn at ogf.org
Thu Jan 28 08:03:50 CST 2010


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)



More information about the Nmc-wg mailing list