perfsonar-dev - nmwg: r231 - trunk/nmwg/doc/nm-schema-base

Subject: perfsonar development work

List archive

nmwg: r231 - trunk/nmwg/doc/nm-schema-base

From:
To: ,
Subject: nmwg: r231 - trunk/nmwg/doc/nm-schema-base
Date: Mon, 7 May 2007 09:28:54 -0400

Author: zurawski
Date: 2007-05-07 09:28:53 -0400 (Mon, 07 May 2007)
New Revision: 231

Added:
trunk/nmwg/doc/nm-schema-base/lines.pl
Modified:
trunk/nmwg/doc/nm-schema-base/make.sh
trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
trunk/nmwg/doc/nm-schema-base/post.pl
Log:
Updated a post processing step to color the schema files.

-jason

Added: trunk/nmwg/doc/nm-schema-base/lines.pl

Property changes on: trunk/nmwg/doc/nm-schema-base/lines.pl
___________________________________________________________________
Name: svn:executable
+ *

Modified: trunk/nmwg/doc/nm-schema-base/make.sh
===================================================================
--- trunk/nmwg/doc/nm-schema-base/make.sh 2007-05-07 13:12:03 UTC (rev
230)
+++ trunk/nmwg/doc/nm-schema-base/make.sh 2007-05-07 13:28:53 UTC (rev
231)
@@ -16,6 +16,12 @@

$JAVA -jar $SAXON -novw -w0 tmp.$INSTANCE.xml $STYLESHEET1 > $INSTANCE.html

+./lines.pl $INSTANCE.html > $INSTANCE-2.html
+
+./post.pl $INSTANCE-2.html > $INSTANCE.html
+
+rm -f $INSTANCE-2.html
+
$JAVA -jar $SAXON -novw -w0 tmp.$INSTANCE.xml $STYLESHEET2 > $INSTANCE.fo

cd $FOPDIR

Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2007-05-07 13:12:03
UTC (rev 230)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.fo 2007-05-07 13:28:53
UTC (rev 231)
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?><fo:root
xmlns:fo="http://www.w3.org/1999/XSL/Format"; font-family="serif"
font-size="10pt"><meta-info
xmlns="http://www.renderx.com/XSL/Extensions";><meta-field name="title"
value="
	An Extensible Schema for Network Measurement and Performance
Data
 "/><meta-field name="author"
value="Swany"/></meta-info><fo:layout-master-set><fo:simple-page-master
master-name="first-page" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages-dc"
margin-left="1in" margin-right="1in" page-height="11in"
page-width="8.5in"><fo:region-body margin-bottom="1in" margin-top="1in"
column-count="2"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:page-sequence-master
master-name="sequence"><fo:single-page-master-reference
master-reference="first-page"/><fo:repeatable-page-master-reference
master-reference="other-pages"/></fo:page-sequence-master></fo:layout-master-set><fo:bookmark-tree><fo:bookmark
internal-destination="rfc.status"><fo:bookmark-title>Status of this
Memo</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.copyrightnotice"><fo:bookmark-title>Copyright
Notice</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.1"><fo:bookmark-title>1
Introduction</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.1.1"><fo:bookmark-title>1.1
Goals</fo:bookmark-title></fo:bookmark></fo
:bookmark><fo:bookmark internal-destination="rfc.section.2">!
<fo:book
mark-title>2 Design Philosophy</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3"><fo:bookmark-title>3 Basic
Elements</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1
Metadata</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1
Subject</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 Event
Type</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3
Parameters</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2
Data</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.2.1"><fo:bookmark-title>3.2.1
Datum</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.3"><fo:bookmark-title>3.3 Container
Elements</fo:bookmark-
title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.5"><fo:bookmark-title>5 Extending the
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.6"><fo:bookmark-title>6
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.7"><fo:bookmark-title>7 Metadata
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.8"><fo:bookmark-title>8 Operation
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.9"><fo:bookmark-title>9 Base
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.10"><fo:bookmark-title>10 Time
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11"><fo:bookmark-title>11 Topology
Schema</fo:bookmark-title></fo:book
mark><fo:bookmark internal-destination="rfc.section.12"><fo:!
bookmark
-title>12 Examples</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.12.1"><fo:bookmark-title>12.1 Schema for
ping</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.12.2"><fo:bookmark-title>12.2 Instance
document for ping</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.13"><fo:bookmark-title>13 Security
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.14"><fo:bookmark-title>14
Appendices</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.14.1"><fo:bookmark-title>14.1
Acknowledgements</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.references"><fo:bookmark-title>15
References</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.authors"><fo:bookmark-title>Author's
Address</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectu
al Property and Copyright
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
master-reference="sequence" language="en"><fo:static-content
flow-name="header"><fo:table width="100%" text-align="center"
space-before=".2cm" table-layout="fixed"><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-column
column-width="proportional-column-width(70)"/><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
text-align="start">GFD </fo:block></fo:table-cell><fo:table-cell
text-align="center"><fo:block>
+<?xml version="1.0" encoding="UTF-8"?><fo:root
xmlns:fo="http://www.w3.org/1999/XSL/Format"; font-family="serif"
font-size="10pt"><meta-info
xmlns="http://www.renderx.com/XSL/Extensions";><meta-field name="title"
value="
	An Extensible Schema for Network Measurement and Performance
Data
 "/><meta-field name="author"
value="Swany"/></meta-info><fo:layout-master-set><fo:simple-page-master
master-name="first-page" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages" margin-left="1in" margin-right="1in"
page-height="11in" page-width="8.5in"><fo:region-body margin-bottom="1in"
margin-top="1in"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:simple-page-master
master-name="other-pages-dc"
margin-left="1in" margin-right="1in" page-height="11in"
page-width="8.5in"><fo:region-body margin-bottom="1in" margin-top="1in"
column-count="2"/><fo:region-before extent="1cm"
region-name="header"/><fo:region-after extent="1cm"
region-name="footer"/></fo:simple-page-master><fo:page-sequence-master
master-name="sequence"><fo:single-page-master-reference
master-reference="first-page"/><fo:repeatable-page-master-reference
master-reference="other-pages"/></fo:page-sequence-master></fo:layout-master-set><fo:bookmark-tree><fo:bookmark
internal-destination="rfc.status"><fo:bookmark-title>Status of this
Memo</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.copyrightnotice"><fo:bookmark-title>Copyright
Notice</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.1"><fo:bookmark-title>1
Introduction</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.1.1"><fo:bookmark-title>1.1
Goals</fo:bookmark-title></fo:bookmark></fo
:bookmark><fo:bookmark internal-destination="rfc.section.2">!
<fo:book
mark-title>2 Design Philosophy</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3"><fo:bookmark-title>3 Basic
Elements</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1"><fo:bookmark-title>3.1
Metadata</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.1.1"><fo:bookmark-title>3.1.1
Subject</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.2"><fo:bookmark-title>3.1.2 Event
Type</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.1.3"><fo:bookmark-title>3.1.3
Parameters</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.2"><fo:bookmark-title>3.2
Data</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.3.2.1"><fo:bookmark-title>3.2.1
Datum</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.3.3"><fo:bookmark-title>3.3 Container
Elements</fo:bookmark-
title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.4"><fo:bookmark-title>4 XML
Namespaces</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.5"><fo:bookmark-title>5 Extending the
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.6"><fo:bookmark-title>6
Versioning</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.7"><fo:bookmark-title>7 Metadata
Chaining</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.8"><fo:bookmark-title>8 Operation
Metadata</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.9"><fo:bookmark-title>9 Base
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.10"><fo:bookmark-title>10 Time
Schema</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.11"><fo:bookmark-title>11 Topology
Schema</fo:bookmark-title></fo:book
mark><fo:bookmark internal-destination="rfc.section.12"><fo:!
bookmark
-title>12 Examples</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.12.1"><fo:bookmark-title>12.1 Schema for
ping</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.12.2"><fo:bookmark-title>12.2 Instance
document for ping</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.section.13"><fo:bookmark-title>13 Security
Concerns</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.section.14"><fo:bookmark-title>14
Appendices</fo:bookmark-title><fo:bookmark
internal-destination="rfc.section.14.1"><fo:bookmark-title>14.1
Acknowledgements</fo:bookmark-title></fo:bookmark></fo:bookmark><fo:bookmark
internal-destination="rfc.references"><fo:bookmark-title>15
References</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.authors"><fo:bookmark-title>Author's
Address</fo:bookmark-title></fo:bookmark><fo:bookmark
internal-destination="rfc.ipr"><fo:bookmark-title>Intellectu
al Property and Copyright
Statements</fo:bookmark-title></fo:bookmark></fo:bookmark-tree><fo:page-sequence
master-reference="sequence" language="en"><fo:static-content
flow-name="header"><fo:table width="100%" text-align="center"
space-before=".2cm" table-layout="fixed"><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-column
column-width="proportional-column-width(70)"/><fo:table-column
column-width="proportional-column-width(6)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
text-align="start">RFC </fo:block></fo:table-cell><fo:table-cell
text-align="center"><fo:block>
An Extensible Schema for Network Measurement and Performance Data
</fo:block></fo:table-cell><fo:table-cell text-align="end"><fo:block>May
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:static-content
flow-name="footer"><fo:table text-align="center" width="100%"
table-layout="fixed"><fo:table-column
column-width="proportional-column-width(7.5)"/><fo:table-column
column-width="proportional-column-width(13)"/><fo:table-column
column-width="proportional-column-width(7.5)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block
text-align="start">Swany</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="center">Informational</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="end">[Page
<fo:page-number/>]</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table></fo:static-content><fo:flow
flow-name="xsl-region-body"><fo:table width="100%"
table-layout="fixed"><fo:table-column
column-width="proportional-column-width(1)"/><fo:table-column
column-width="proportio

nal-column-width(1)"/><fo:table-body><fo:table-row><fo:table-cell><fo:block>Network
Measurement Working Group</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="right">M Swany,
Editor</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block/></fo:table-cell><fo:table-cell><fo:block

text-align="right">UDel</fo:block></fo:table-cell></fo:table-row><fo:table-row><fo:table-cell><fo:block>Intended
status: Informational</fo:block></fo:table-cell><fo:table-cell><fo:block
text-align="right">May
2007</fo:block></fo:table-cell></fo:table-row></fo:table-body></fo:table><fo:block
text-align="center" font-weight="bold" font-size="18pt" space-before="3em"
space-after="3em">
An Extensible Schema for Network Measurement and Performance Data
@@ -180,10 +180,11 @@
</fo:block><fo:block font-weight="bold" font-size="14pt"
keep-with-next="always" space-after="7pt" page-break-before="always"
id="rfc.section.9">9. Base Schema</fo:block><fo:block space-before=".5em"
space-after=".5em" start-indent="2em">
<fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">#
##############################################################
#
-# File: nmbase.rnc - Main schema definition
-# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This is the main schema file, it defines the
-# general structure of an NMWG message or store
+# File: nmbase.rnc - Main schema definition
+# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
+# Purpose: This is the main relax schema file, it defines
+# the general makeup of an NMWG structured message.
+# Reference: http://books.xmlschemata.org/relaxng/page2.html
#
# ##############################################################

@@ -201,8 +202,8 @@
include "filter.rnc"

# ##############################################################
-# Every NMWG document should begin with either a 'store' or
-# 'message' element
+# Every suitable NMWG document should begin with either a
+# 'store' or 'message' element, in the appropriate namespace.
# Patterns are defined for the content of each element.
#
# Example (using message):
@@ -212,11 +213,11 @@
# type="REQUIRED_TYPE"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
-# 
+# 
#
-# 
+# 
#
-# 
+# 
#
# </nmwg:message>
#
@@ -255,10 +256,13 @@

# ##############################################################
-# Metadata is the information that describes data. This
-# information doesn't change over time
+# Metadata is the 'data' that describes physical measurements.
+# Metadata can be a physical address or a geographical location;
+# any form of static, re-usable designation. It is important to
+# note that the subject namespace and parameters namespace MUST
+# match (or the parameters can be a generic NMWG) or bad things
+# will occur.
#
-#
# Example:
#
# <nmwg:metadata id="REQUIRED_ID"
@@ -488,15 +492,12 @@
}

# ##############################################################
-# CommonTime is used as a shortcut that is able to 'factor out'
-# a frequently occurring time range that a group of datum (or
-# other) elements might share, thus reducing the verbosity of the
-# XML representation. CommonTime is similar to the other NMWG time
+# CommonTime is used as a shortcut that is able to 'factor out'
+# a frequently occurring time range that a bunch of datum (or
+# other) elements might share, thus reducing complexity of XML
+# representation. CommonTime is similar to the other NMWG time
# stamps (from nmtime.rnc) in its potential time representations.
#
-# It is unfortunate that it needs to be in this file and not
-# nmtime.rnc, but as it occurs outside the datum, it is here.
-#
# Example:
#
# <nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
@@ -504,13 +505,11 @@
# inclusive="OPTIONAL_INCLUSIVE_FLAG"
# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
#
-# 
+# 
#
# 
#
-# 
+# 
#
# 
#
@@ -624,10 +623,12 @@

<fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">#
##############################################################
#
-# File: nmtime.rnc - NMWG Time definitions
-# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This describes a set of time formats for
-# representing measurements.
+# File: nmtime.rnc - NMWG Time definitions
+# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
+# Purpose: This describes a general time format for
+# representing measurements. It is far from complete,
+# and may be best represented by other methods.
+# Reference: http://books.xmlschemata.org/relaxng/page2.html
#
# ##############################################################

@@ -708,9 +709,13 @@

<fo:block font-family="monospace" font-size="9pt"
background-color="#dddddd" white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">#
##############################################################
#
-# File: nmtopo.rnc - Schema to describe topological
+# File: nmtopo.rnc - Schema to describe topological
+# features to be used in subject
# elements.
-# Version: $Id: nmtopo.rnc 209 2007-02-15 17:20:25Z zurawski $
+# Version: $Id: nmtopo.rnc 209 2007-02-15 17:20:25Z zurawski $
+# Purpose: This file lays out some major network topologies
+# used in measurement.
+# Reference: http://books.xmlschemata.org/relaxng/page2.html
#
# ##############################################################

@@ -856,8 +861,10 @@
# File: ping.rnc - Specialized schema for the ping
# tool
# Version: $Id: ping.rnc 205 2007-02-05 17:33:00Z zurawski $
-# Purpose: Defines elements to be used in the representation
-# of ping measurements.
+# Purpose: Describes specific elements to be used in the
+# representation and handling of ping
+# measurements.
+# Reference: http://books.xmlschemata.org/relaxng/page2.html
#
# ##############################################################

@@ -883,7 +890,31 @@

# ##############################################################
-# Metadata
+# Metadata is the 'data' that describes physical measurements.
+# Metadata can be something such as a physical address, or
+# a geographical location; any form of static, re-usable
+# designation. It is important to note that the subject
+# namespace and parameters namespace MUST match (or the parameters
+# can be a generic NMWG) or bad things will occur.
+#
+# Example:
+#
+# <nmwg:metadata id="REQUIRED_ID"
+# metadataIdRef="OPTIONAL_REFERENCE_ID"
+# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+#
+# 
+#
+# 
+#
+# 
+#
+# 
+#
+# 
+#
+# </nmwg:metadata>
+#
# ##############################################################

PingMetadata =
@@ -1047,7 +1078,30 @@

# ##############################################################
-# CommonTime
+# CommonTime is used a a shortcut able to 'factor out' a frequently
+# occurring time range that a bunch of datum (or other) elements
+# might share, thus reducing complexity of XML representation.
+# CommonTime is similar to the other NMWG time stamps (from
+# nmtime.rnc) in its potential time representations.
+#
+# Example:
+#
+# <nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
+# duration="OPTIONAL_DURATION"
+# inclusive="OPTIONAL_INCLUSIVE_FLAG"
+# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+#
+# 
+#
+# 
+#
+# 
+#
+# 
+#
+# 
+# </nmwg:commonTime>
+#
# ##############################################################

PingCommonTime =
@@ -1195,4 +1249,4 @@
other proprietary rights, which may cover technology that
may be required to practice this recommendation. Please
address the information to the OGF Executive Director.
- </fo:block></fo:flow></fo:page-sequence></fo:root>
+ </fo:block></fo:flow></fo:page-sequence></fo:root>
\ No newline at end of file

Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.html
===================================================================
--- trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2007-05-07 13:12:03
UTC (rev 230)
+++ trunk/nmwg/doc/nm-schema-base/nm-schema-base.html 2007-05-07 13:28:53
UTC (rev 231)
@@ -1,8 +1,12 @@
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html lang="en"><head><meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"><title>
+<html lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<title>
An Extensible Schema for Network Measurement and Performance Data
- </title><style type="text/css" title="Xml2Rfc (sans serif)">
+ </title>
+<style type="text/css" title="Xml2Rfc (sans serif)">
a {
text-decoration: none;
}
@@ -293,62 +297,186 @@
content: normal;
}
}
-</style><link rel="Author" href="#rfc.authors"><link rel="Copyright"
href="#rfc.copyright"><link rel="Chapter" title="1 Introduction"
href="#rfc.section.1"><link rel="Chapter" title="2 Design Philosophy"
href="#rfc.section.2"><link rel="Chapter" title="3 Basic Elements"
href="#rfc.section.3"><link rel="Chapter" title="4 XML Namespaces"
href="#rfc.section.4"><link rel="Chapter" title="5 Extending the Schema"
href="#rfc.section.5"><link rel="Chapter" title="6 Versioning"
href="#rfc.section.6"><link rel="Chapter" title="7 Metadata Chaining"
href="#rfc.section.7"><link rel="Chapter" title="8 Operation Metadata"
href="#rfc.section.8"><link rel="Chapter" title="9 Base Schema"
href="#rfc.section.9"><link rel="Chapter" title="10 Time Schema"
href="#rfc.section.10"><link rel="Chapter" title="11 Topology Schema"
href="#rfc.section.11"><link rel="Chapter" title="12 Examples"
href="#rfc.section.12"><link rel="Chapter" title="13 Security Concerns"
href="#rfc.section.13"><link rel="Chapte
r" title="14 Appendices" href="#rfc.section.14"><link rel="Chapter"
href="#rfc.section.15" title="15 References"><meta name="generator"
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291,
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica
http://www.saxonica.com/";><link rel="schema.DC"
href="http://purl.org/dc/elements/1.1/";><meta name="DC.Creator"
content="Swany, M"><meta name="DC.Date.Issued" scheme="ISO8601"
content="2007-05"></head><body><table summary="header information"
class="header" border="0" cellpadding="1" cellspacing="1"><tr><td
class="front left">Network Measurement Working Group</td><td class="front
right">M Swany, Editor</td></tr><tr><td class="front left"></td><td
class="front right">UDel</td></tr><tr><td class="front left">Intended status:
Informational</td><td class="front right">May 2007</td></tr></table>An Extensible Schema for Network Measurement and Performance
Data<h1><a id="rfc.status" href="#rfc.status
">Status of this Memo</a></h1>This memo provides informat!
ion for
the Grid community. It does not specify any standards or technical
recommendations. Distribution is unlimited.<h1><a
id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright
Notice</a></h1>Copyright � The Open Grid Forum (2007). All Rights
Reserved.<hr class="noprint"><h1 id="rfc.section.1" class="np"><a
href="#rfc.section.1">1.</a> <a id="intro"
href="#intro">Introduction</a></h1>This document
presents an extensible encoding standard for network measurement and
performance data. Uniform encoding of this class of information is a key
problem for federated network management, and multi-domain dynamic
provisioning of network circuits, as well as in advanced distributed
computing environments, such as Grid computing.This work is born of the need for a common mechanism
for the exchange of network measurement and performance data. In the case of
research-oriented networks, parties often want to exchange
network performance data with neighbors for debugging purposes. In general,
however, there is no single system that is in use. In the Grid community, the
need to exchange network metrics of various sorts is often highlighted. In
short it is highly desirable to have an extensible schema for network
performance information that gives a common, general framework for
representation and exchange.This document
builds on previous versions of the network measurement schemata. This
document describes Version 2 of the Grid Forum's Network Measurement Working
Group (NM-WG) schema.<h2 id="rfc.section.1.1"><a
href="#rfc.section.1.1">1.1</a> Goals</h2>The goal is to define a neutral representation for
network measurements that can be easily extended to support new types of
data. This representation should identify forms of network performance data
as well as to create standardized mechanism to both describe and publish the
se metrics.<hr class="noprint"><h1 id="rfc.section.2" cl!
ass="np"
><a href="#rfc.section.2">2.</a> Design Philosophy</h1><p
>id="rfc.section.2.p.1">One of the high-level goals of this representation is
>to "normalize" the data representation by removing as much redundancy as
>possible. The basic schema design is based on the observation that network
>measurement data can be divided into two major classes. The first class is
>the Metadata, which describes the type of measurement data, the entity or
>entities being measured and the particular parameters of the measurement.
>The second class is the data itself, which is, at its simplest, a timestamp
>and a value, or vector of values. This division of Metadata and Data is
>present throughout the system. This structure is present both in the
>"Messages" sent between various data elements and in data "Stores" --
>persistent storage of XML documents representing system state.<hr
>class="noprint"><h1 id="rfc.section.3" class="np"><a
>href="#rfc.section.3">3.</a> Basic Elements</h1>This schema defines the basic elements that can be used to
represent performance data. The first distinction is between the "Metadata",
the relatively static information regarding the data, and the "Data" itself,
which generally changes over time. The key idea is that, for repeated
measurements, which is a common case for performance data in networks and
Grids, the Metadata need not be repeated with each measurement, saving space
and effort.Each top-level element in this
schema has an Identifier attribute called "Id". There are many cases in which
one element needs to refer to another. For these cases an Id Reference is
used. Note that we have not used the XML Schema ID and IDREF types, although
they seem to be appropriate. The reason is that for an IDREF, the
corresponding ID must appear in the same document. We envision remote Id
references (with e.g., a generic URL or a WS-Addressing EPR) and thus find
this limitation overly restric
tive. (Note that another possibility is the use of a simple !
element
to resolve the local ID and point to remote Metadata.)<h2
id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> Metadata</h2>The Metadata must describe the Data unambiguously.
To accomplish this, the Metadata must include three key things:<dl
class="empty"><dd>"Subject" -- The Subject identifies the entity being
measured. This could include the network path between a pair of hosts, an
interface on a router, or a specific location on the network from which flow
or packet data is captured.</dd><dd>"EventType" -- The EventType identifies
exactly what sort of measurement Event occurred.</dd><dd>"Parameters" -- The
Parameters describe the details of the measurement.</dd></dl><h3
id="rfc.section.3.1.1"><a
href="#rfc.section.3.1.1">3.1.1</a> Subject</h3>The "Subject" identifies the measured entity. For
networks, this may represent a path between two hosts or an interface on a
network device.<h3 id="rfc
.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> Event
Type</h3>The "Event Type" is the canonical name
of the aspect of the subject being measured, or the actual event (i.e.
"characteristic") being reported.<h3 id="rfc.section.3.1.3"><a
href="#rfc.section.3.1.3">3.1.3</a> Parameters</h3>The "Parameters" describe the exact way in which a
particular measurement was gathered. These can include parameters to active
measurement tools. Essentially, anything needed to determine which
measurements are fungible should be included here. Parameters take the form
of name, value pairs. The value of a parameter can itself be a complex XML
element.<h2 id="rfc.section.3.2"><a
href="#rfc.section.3.2">3.2</a> Data</h2>The
"Data" element has an Identifier (Id) and an Identifier Reference
(metadataIdRef) that refers to the "Metadata" that describes it. It contains
some number of
"Datum" elements.<h3 id="rfc.section.3.2.1"><a href="#rf!
c.sectio
n.3.2.1">3.2.1</a> Datum</h3>The "Datum"
elements hold the timestamp and value of the measurement or value of the
event. For many network measurement data sources, this can be a time-series
of timestamp, value pairs. For other measurement types, the result value may
be a vector.<h2 id="rfc.section.3.3"><a
href="#rfc.section.3.3">3.3</a> Container Elements</h2>The above-named elements are currently contained in
two types of outer elements, "Message" and "Store". They have exactly the
same structure, i.e. containing "Metadata" and "Data" elements. Each may have
an attribute called "Type" to indicate its type. Each may also contain one
"Parameters" element to indicate Message- or Store-level parameters and
options. This allows for a great deal of customization.<hr
class="noprint"><h1 id="rfc.section.4" class="np"><a
href="#rfc.section.4">4.</a> XML Namespaces</h1>A key face
t in this schema is the observation that the above elements can be used to
describe any network measurement, but the exact content of the each will vary
with the measurement type. We have adopted XML namespaces to allow reuse of
these same basic element names, but to vary the contents of the basic
elements for each different type of data.In
this way, some superficial examination of the structure of a message or
information store can take place without looking at the details of the
contents. Some processing functionality should be able to consume new data
types with no modification.We envision there
being two major classes of namespace URIs. The first is a canonical name
based on the Hierarchy of Network Measurements from this working group.
(cite). The second is based on an organization's domain name and allows for
autonomous extension in much the same way as the Enterprise branch of the OID
space (cite) allows. Fin
ally, as this specification doesn't address the embedding of!
this sc
hema into other systems, we note that the relevant parts of the namespace can
be appended to another namespace if one is already in use.<hr
class="noprint"><h1 id="rfc.section.5" class="np"><a
href="#rfc.section.5">5.</a> Extending the Schema</h1>The namespace-based approach described above provides
extensibility by defining new basic elements in a tool- or
characteristic-specific namespace. An example of this is presented in the
Ping example later.This needs some textual
description.<hr class="noprint"><h1 id="rfc.section.6" class="np"><a
href="#rfc.section.6">6.</a> Versioning</h1>While the working group has made every effort to
completely describe a few measurement types, we are well aware that tools,
and ideas about how to represent them, may change. For this reason, each of
the schema areas must have a version number.To
accomplish this, each o
f the URIs that comprise the namespaces end in a version number. TBD,
conforming to recent GFD on namespaces.<hr class="noprint"><h1
id="rfc.section.7" class="np"><a href="#rfc.section.7">7.</a> Metadata
Chaining</h1>While a complete Metadata block can be
used to unambiguously describe a data block, it is often desirable to combine
multiple, partial Metadata blocks together. The main reason for this is reuse
of information. Using the "metadataIdRef" attribute of a Metadata block
allows us to form a "chain" of Metadata blocks. This means that not all
Metadata blocks will have an associated eventType. At the end of the chain,
however, there MUST be an event type.<hr class="noprint"><h1
id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a> Operation
Metadata</h1>In addition to describing sets of raw
data, Metadata blocks can also be used to describe transformation operations
performed on a set of data
. Thus, a list of Metadata blocks, including origin and tran!
sformati
ons, can be used to unambiguously describe the provenance of any network
data. This can also be used in cases where the transformation is "internal"
and the original data is not available. This can be thought of as describing
set operations on the original set as it passes through a list of operators.
One example of this is the selection of a
subset of data from a a set, based on time or value. A "select" metadata
block can be used to describe this filtering operation independent of the
source. Formally, we can think of this as as an operation on one set that
produces another set. This metadata block must unambiguously defining that
set operation.This relationship between
Metadata blocks is expressed by having the Subject metadataIdRef refer to
another Metadata, which denotes having it be input to an operation.<hr
class="noprint"><h1 id="rfc.section.9" class="np"><a
href="#rfc.section.9">9.</a> Base Schema</
h1> <pre>
-# ##############################################################
-#
-# File: nmbase.rnc - Main schema definition
-# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This is the main schema file, it defines the
-# general structure of an NMWG message or store
-#
-# ##############################################################
+</style>
+<link rel="Author" href="#rfc.authors">
+<link rel="Copyright" href="#rfc.copyright">
+<link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
+<link rel="Chapter" title="2 Design Philosophy" href="#rfc.section.2">
+<link rel="Chapter" title="3 Basic Elements" href="#rfc.section.3">
+<link rel="Chapter" title="4 XML Namespaces" href="#rfc.section.4">
+<link rel="Chapter" title="5 Extending the Schema" href="#rfc.section.5">
+<link rel="Chapter" title="6 Versioning" href="#rfc.section.6">
+<link rel="Chapter" title="7 Metadata Chaining" href="#rfc.section.7">
+<link rel="Chapter" title="8 Operation Metadata" href="#rfc.section.8">
+<link rel="Chapter" title="9 Base Schema" href="#rfc.section.9">
+<link rel="Chapter" title="10 Time Schema" href="#rfc.section.10">
+<link rel="Chapter" title="11 Topology Schema" href="#rfc.section.11">
+<link rel="Chapter" title="12 Examples" href="#rfc.section.12">
+<link rel="Chapter" title="13 Security Concerns" href="#rfc.section.13">
+<link rel="Chapter" title="14 Appendices" href="#rfc.section.14">
+<link rel="Chapter" href="#rfc.section.15" title="15 References">
+<meta name="generator"
content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.291,
2006/10/29 09:03:19, XSLT vendor: SAXON 8.8 from Saxonica
http://www.saxonica.com/";>
+<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/";>
+<meta name="DC.Creator" content="Swany, M">
+<meta name="DC.Date.Issued" scheme="ISO8601" content="2007-05">
+</head>
+<body>
+<table summary="header information" class="header" border="0"
cellpadding="1" cellspacing="1">
+<tr>
+<td class="front left">Network Measurement Working Group</td>
+<td class="front right">M Swany, Editor</td>
+</tr>
+<tr>
+<td class="front left">
+</td>
+<td class="front right">UDel</td>
+</tr>
+<tr>
+<td class="front left">Intended status: Informational</td>
+<td class="front right">May 2007</td>
+</tr>
+</table>
+An Extensible Schema for Network Measurement and
Performance Data
+<h1>
+<a id="rfc.status" href="#rfc.status">Status of this Memo</a>
+</h1>
+This memo provides information for the Grid community. It does not
specify any standards or technical recommendations. Distribution is
unlimited.
+<h1>
+<a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a>
+</h1>
+Copyright � The Open Grid Forum (2007). All Rights Reserved.
+<hr class="noprint">
+<h1 id="rfc.section.1" class="np">
+<a href="#rfc.section.1">1.</a> <a id="intro"
href="#intro">Introduction</a>
+</h1>
+This document presents an extensible encoding
standard for network measurement and performance data. Uniform encoding of
this class of information is a key problem for federated network management,
and multi-domain dynamic provisioning of network circuits, as well as in
advanced distributed computing environments, such as Grid computing.
+This work is born of the need for a common
mechanism for the exchange of network measurement and performance data. In
the case of research-oriented networks, parties often want to exchange
network performance data with neighbors for debugging purposes. In general,
however, there is no single system that is in use. In the Grid community, the
need to exchange network metrics of various sorts is often highlighted. In
short it is highly desirable to have an extensible schema for network
performance information that gives a common, general framework for
representation and exchange.
+This document builds on previous versions of the
network measurement schemata. This document describes Version 2 of the Grid
Forum's Network Measurement Working Group (NM-WG) schema.
+<h2 id="rfc.section.1.1">
+<a href="#rfc.section.1.1">1.1</a> Goals</h2>
+The goal is to define a neutral representation
for network measurements that can be easily extended to support new types of
data. This representation should identify forms of network performance data
as well as to create standardized mechanism to both describe and publish
these metrics.
+<hr class="noprint">
+<h1 id="rfc.section.2" class="np">
+<a href="#rfc.section.2">2.</a> Design Philosophy</h1>
+One of the high-level goals of this representation
is to "normalize" the data representation by removing as much redundancy as
possible. The basic schema design is based on the observation that network
measurement data can be divided into two major classes. The first class is
the Metadata, which describes the type of measurement data, the entity or
entities being measured and the particular parameters of the measurement. The
second class is the data itself, which is, at its simplest, a timestamp and a
value, or vector of values. This division of Metadata and Data is present
throughout the system. This structure is present both in the "Messages" sent
between various data elements and in data "Stores" -- persistent storage of
XML documents representing system state.
+<hr class="noprint">
+<h1 id="rfc.section.3" class="np">
+<a href="#rfc.section.3">3.</a> Basic Elements</h1>
+This schema defines the basic elements that can be
used to represent performance data. The first distinction is between the
"Metadata", the relatively static information regarding the data, and the
"Data" itself, which generally changes over time. The key idea is that, for
repeated measurements, which is a common case for performance data in
networks and Grids, the Metadata need not be repeated with each measurement,
saving space and effort.
+Each top-level element in this schema has an
Identifier attribute called "Id". There are many cases in which one element
needs to refer to another. For these cases an Id Reference is used. Note that
we have not used the XML Schema ID and IDREF types, although they seem to be
appropriate. The reason is that for an IDREF, the corresponding ID must
appear in the same document. We envision remote Id references (with e.g., a
generic URL or a WS-Addressing EPR) and thus find this limitation overly
restrictive. (Note that another possibility is the use of a simple element to
resolve the local ID and point to remote Metadata.)
+<h2 id="rfc.section.3.1">
+<a href="#rfc.section.3.1">3.1</a> Metadata</h2>
+The Metadata must describe the Data
unambiguously. To accomplish this, the Metadata must include three key
things:
+<dl class="empty">
+<dd>"Subject" -- The Subject identifies the entity being measured. This
could include the network path between a pair of hosts, an interface on a
router, or a specific location on the network from which flow or packet data
is captured.</dd>
+<dd>"EventType" -- The EventType identifies exactly what sort of measurement
Event occurred.</dd>
+<dd>"Parameters" -- The Parameters describe the details of the
measurement.</dd>
+</dl>
+<h3 id="rfc.section.3.1.1">
+<a href="#rfc.section.3.1.1">3.1.1</a> Subject</h3>
+The "Subject" identifies the measured entity.
For networks, this may represent a path between two hosts or an interface on
a network device.
+<h3 id="rfc.section.3.1.2">
+<a href="#rfc.section.3.1.2">3.1.2</a> Event Type</h3>
+The "Event Type" is the canonical name of the
aspect of the subject being measured, or the actual event (i.e.
"characteristic") being reported.
+<h3 id="rfc.section.3.1.3">
+<a href="#rfc.section.3.1.3">3.1.3</a> Parameters</h3>
+The "Parameters" describe the exact way in
which a particular measurement was gathered. These can include parameters to
active measurement tools. Essentially, anything needed to determine which
measurements are fungible should be included here. Parameters take the form
of name, value pairs. The value of a parameter can itself be a complex XML
element.
+<h2 id="rfc.section.3.2">
+<a href="#rfc.section.3.2">3.2</a> Data</h2>
+The "Data" element has an Identifier (Id) and an
Identifier Reference (metadataIdRef) that refers to the "Metadata" that
describes it. It contains some number of "Datum" elements.
+<h3 id="rfc.section.3.2.1">
+<a href="#rfc.section.3.2.1">3.2.1</a> Datum</h3>
+The "Datum" elements hold the timestamp and
value of the measurement or value of the event. For many network measurement
data sources, this can be a time-series of timestamp, value pairs. For other
measurement types, the result value may be a vector.
+<h2 id="rfc.section.3.3">
+<a href="#rfc.section.3.3">3.3</a> Container Elements</h2>
+The above-named elements are currently contained
in two types of outer elements, "Message" and "Store". They have exactly the
same structure, i.e. containing "Metadata" and "Data" elements. Each may have
an attribute called "Type" to indicate its type. Each may also contain one
"Parameters" element to indicate Message- or Store-level parameters and
options. This allows for a great deal of customization.
+<hr class="noprint">
+<h1 id="rfc.section.4" class="np">
+<a href="#rfc.section.4">4.</a> XML Namespaces</h1>
+A key facet in this schema is the observation that
the above elements can be used to describe any network measurement, but the
exact content of the each will vary with the measurement type. We have
adopted XML namespaces to allow reuse of these same basic element names, but
to vary the contents of the basic elements for each different type of
data.
+In this way, some superficial examination of the
structure of a message or information store can take place without looking at
the details of the contents. Some processing functionality should be able to
consume new data types with no modification.
+We envision there being two major classes of
namespace URIs. The first is a canonical name based on the Hierarchy of
Network Measurements from this working group. (cite). The second is based on
an organization's domain name and allows for autonomous extension in much the
same way as the Enterprise branch of the OID space (cite) allows. Finally, as
this specification doesn't address the embedding of this schema into other
systems, we note that the relevant parts of the namespace can be appended to
another namespace if one is already in use.
+<hr class="noprint">
+<h1 id="rfc.section.5" class="np">
+<a href="#rfc.section.5">5.</a> Extending the Schema</h1>
+The namespace-based approach described above
provides extensibility by defining new basic elements in a tool- or
characteristic-specific namespace. An example of this is presented in the
Ping example later.
+This needs some textual description.
+<hr class="noprint">
+<h1 id="rfc.section.6" class="np">
+<a href="#rfc.section.6">6.</a> Versioning</h1>
+While the working group has made every effort to
completely describe a few measurement types, we are well aware that tools,
and ideas about how to represent them, may change. For this reason, each of
the schema areas must have a version number.
+To accomplish this, each of the URIs that comprise
the namespaces end in a version number. TBD, conforming to recent GFD on
namespaces.
+<hr class="noprint">
+<h1 id="rfc.section.7" class="np">
+<a href="#rfc.section.7">7.</a> Metadata Chaining</h1>
+While a complete Metadata block can be used to
unambiguously describe a data block, it is often desirable to combine
multiple, partial Metadata blocks together. The main reason for this is reuse
of information. Using the "metadataIdRef" attribute of a Metadata block
allows us to form a "chain" of Metadata blocks. This means that not all
Metadata blocks will have an associated eventType. At the end of the chain,
however, there MUST be an event type.
+<hr class="noprint">
+<h1 id="rfc.section.8" class="np">
+<a href="#rfc.section.8">8.</a> Operation Metadata</h1>
+In addition to describing sets of raw data,
Metadata blocks can also be used to describe transformation operations
performed on a set of data. Thus, a list of Metadata blocks, including origin
and transformations, can be used to unambiguously describe the provenance of
any network data. This can also be used in cases where the transformation is
"internal" and the original data is not available. This can be thought of as
describing set operations on the original set as it passes through a list of
operators. 
+One example of this is the selection of a subset
of data from a a set, based on time or value. A "select" metadata block can
be used to describe this filtering operation independent of the source.
Formally, we can think of this as as an operation on one set that produces
another set. This metadata block must unambiguously defining that set
operation.
+This relationship between Metadata blocks is
expressed by having the Subject metadataIdRef refer to another Metadata,
which denotes having it be input to an operation.
+<hr class="noprint">
+<h1 id="rfc.section.9" class="np">
+<a href="#rfc.section.9">9.</a> Base Schema</h1>
+
+<pre>
+#
##############################################################
+# 
+# File: nmbase.rnc - Main schema definition
+# Version: $Id: nmbase.rnc 225 2007-05-02 18:16:45Z
zurawski $
+# Purpose: This is the main relax schema file, it
defines 
+# the general makeup of an NMWG structured
message.
+# Reference:
http://books.xmlschemata.org/relaxng/page2.html
+# 
+#
##############################################################

-# ##############################################################
-# Namespace definitions
-# ##############################################################
-namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
+#
##############################################################
+# Namespace definitions
+#
##############################################################
+namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";

-# ##############################################################
-# Include additional functionality from other files
-# ##############################################################
-include "nmtime.rnc"
-include "filter.rnc"
+#
##############################################################
+# Include additional functionality from other files
+#
##############################################################
+include "nmtime.rnc"
+include "filter.rnc"

-# ##############################################################
-# Every NMWG document should begin with either a 'store' or
-# 'message' element
-# Patterns are defined for the content of each element.
-#
-# Example (using message):
-#
-# <nmwg:message id="OPTIONAL_ID"
-# messageIdRef="OPTIONAL_REFERENCE_ID"
-# type="REQUIRED_TYPE"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# 
-#
-# 
-#
-# </nmwg:message>
-#
-# ##############################################################
+#
##############################################################
+# Every suitable NMWG document should begin with either a

+# 'store' or 'message' element, in the appropriate
namespace.
+# Patterns are defined for the content of each
element.
+# 
+# Example (using message):
+# 
+# <nmwg:message id="OPTIONAL_ID" 
+# messageIdRef="OPTIONAL_REFERENCE_ID"
+# type="REQUIRED_TYPE"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+#
+# 
+# 
+# 
+# 
+# </nmwg:message>
+# 
+#
##############################################################

-start =
+start =
(
- element nmwg:message {
+ element nmwg:message {
MessageContent
} |
- element nmwg:store {
+ element nmwg:store {
StoreContent
}
)

-MessageContent =
+MessageContent =
Identifier? &
MessageIdentifierRef? &
Type &
@@ -359,7 +487,7 @@
)+

-StoreContent =
+StoreContent = 
Identifier? &
MessageIdentifierRef? &
Type &
@@ -370,33 +498,36 @@
)+

-# ##############################################################
-# Metadata is the information that describes data. This
-# information doesn't change over time
-#
-#
-# Example:
-#
-# <nmwg:metadata id="REQUIRED_ID"
-# metadataIdRef="OPTIONAL_REFERENCE_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# </nmwg:metadata>
-#
-# ##############################################################
+#
##############################################################
+# Metadata is the 'data' that describes physical
measurements.
+# Metadata can be a physical address or a geographical
location;
+# any form of static, re-usable designation. It is important
to
+# note that the subject namespace and parameters namespace
MUST
+# match (or the parameters can be a generic NMWG) or bad
things
+# will occur.
+#
+# Example: 
+# 
+# <nmwg:metadata id="REQUIRED_ID" 
+# metadataIdRef="OPTIONAL_REFERENCE_ID"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# 
+#
+# 
+# 
+# 
+# 
+#  
+#
+# </nmwg:metadata>
+# 
+#
##############################################################

-Metadata =
- element nmwg:metadata {
+Metadata = 
+ element nmwg:metadata {
(
Identifier &
MetadataIdentifierRef? &
@@ -405,11 +536,11 @@
anyElement*
}

-MetadataBlock =
+MetadataBlock =
Subject? &
Parameters?

-MetadataContent =
+MetadataContent = 
(
MetadataBlock |
FilterMetadataBlock
@@ -418,31 +549,31 @@
Key?

-# ##############################################################
-# Subject identifies an endPoint (or points), perhaps the name of
-# a service or some other form of physical location. For the
-# purpose of the general case, we make no assumptions on potential
-# elements and allow all elements, in any namespace. Verification
-# can be handled in subsequent schema files.
-#
-# Example:
-#
-# <nmwg:subject id="REQUIRED_ID"
-# metadataIdRef="OPTIONAL_REFERENCE_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# </nmwg:subject>
-#
-# ##############################################################
+#
##############################################################
+# Subject identifies an endPoint (or points), perhaps the
name of
+# a service or some other form of physical location. For
the
+# purpose of the general case, we make no assumptions on
potential
+# elements and allow all elements, in any namespace.
Verification
+# can be handled in subsequent schema files. 
+#
+# Example: 
+# 
+# <nmwg:subject id="REQUIRED_ID" 
+# metadataIdRef="OPTIONAL_REFERENCE_ID"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# </nmwg:subject>
+# 
+#
##############################################################

-Subject =
- element nmwg:subject {
+Subject = 
+ element nmwg:subject {
SubjectContent
}

-SubjectContent =
+SubjectContent = 
(
Identifier &
MetadataIdentifierRef?
@@ -450,50 +581,50 @@
anyElement*

-# ##############################################################
-# Parameters and Parameter elements can be used in a number of
-# ways in: 1) the message to signify items such as time stamp
-# or authorization or 2) metadata or data to specify filters or
-# special cases for the information. A 'parameters' block
-# has an id and encloses one to many 'parameter' elements.
-# These elements have a required 'name', and may contain
-# an attribute, element, or text value (only one please;
-# software using this should consider complex elements, then
-# text, and finally the value attribute; exceptions should
-# be thrown on duplicates).
-#
-# Example:
-#
-# <nmwg:parameters id="REQUIRED_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# <nmwg:parameter name="REQUIRED_NAME" value="OPTIONAL_VALUE"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# </nmwg:parameter>
-#
-# 
-#
-# </nmwg:parameters>
-#
-# The namespaces can of course be different.
-#
-# ##############################################################
+#
##############################################################
+# Parameters and Parameter elements can be used in a number
of
+# ways in: 1) the message to signify items such as time
stamp
+# or authorization or 2) metadata or data to specify filters
or
+# special cases for the information. A 'parameters'
block
+# has an id and encloses one to many 'parameter'
elements.
+# These elements have a required 'name', and may
contain
+# an attribute, element, or text value (only one
please;
+# software using this should consider complex elements,
then
+# text, and finally the value attribute; exceptions
should
+# be thrown on duplicates).
+#
+# Example: 
+# 
+# <nmwg:parameters id="REQUIRED_ID" 
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# <nmwg:parameter name="REQUIRED_NAME"
value="OPTIONAL_VALUE"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# </nmwg:parameter>
+# 
+# 
+# 
+# </nmwg:parameters>
+# 
+# The namespaces can of course be different.
+# 
+#
##############################################################

-Parameters =
- element nmwg:parameters {
+Parameters = 
+ element nmwg:parameters {
ParametersContent
}

-ParametersContent =
+ParametersContent = 
Identifier &
Parameter+

-Parameter =
- element nmwg:parameter {
+Parameter = 
+ element nmwg:parameter {
attribute name { xsd:string } &
(
attribute value { xsd:string } |
@@ -505,43 +636,43 @@
}

-# ##############################################################
-# Event type is a simple text element used to describe the
-# characteristic or event of the data.
-#
-# Example:
-#
-# <nmwg:eventType xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# </nmwg:eventType>
-#
-# ##############################################################
+#
##############################################################
+# Event type is a simple text element used to describe
the
+# characteristic or event of the data.
+#
+# Example: 
+# 
+# <nmwg:eventType
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# </nmwg:eventType>
+# 
+#
############################################################## 

-EventType =
- element nmwg:eventType { xsd:string }
+EventType =
+ element nmwg:eventType { xsd:string }

-# ##############################################################
-# The key is used to return a 'pointer' or otherwise special piece
-# of identifying information in response to a request. For now,
-# this information is enclosed only within a parameters block.
-# The optional ID can be used to track past searches.
-#
-# Example:
-#
-# <nmwg:key id="OPTIONAL_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# </nmwg:key>
-#
-# ##############################################################
+#
##############################################################
+# The key is used to return a 'pointer' or otherwise special
piece
+# of identifying information in response to a request. For
now, 
+# this information is enclosed only within a parameters
block.
+# The optional ID can be used to track past searches.
+#
+# Example: 
+# 
+# <nmwg:key id="OPTIONAL_ID" 
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# </nmwg:key>
+# 
+#
##############################################################

-Key =
- element nmwg:key {
+Key = 
+ element nmwg:key {
Identifier? &
(
Parameters |
@@ -550,43 +681,43 @@
}

-# ##############################################################
-# The data block is complex and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet.
-#
-# Example:
-#
-# <nmwg:data id="REQUIRED_ID"
-# metadataIdRef="OPTIONAL_REFERENCE_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# </nmwg:data>
-#
-# ##############################################################
+#
##############################################################
+# The data block is complex and has the potential to
contain
+# many things. The data block can be used to return a
metadata
+# block from a request, commonTime or datum elements,
keys,
+# or something that we have perhaps not defined as of yet.

+#
+# Example: 
+# 
+# <nmwg:data id="REQUIRED_ID" 
+# metadataIdRef="OPTIONAL_REFERENCE_ID" 
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# 
+#
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# </nmwg:data>
+# 
+#
##############################################################

-Data =
- element nmwg:data {
+Data =
+ element nmwg:data {
(
Identifier &
MetadataIdentifierRef? &
@@ -603,40 +734,35 @@
anyElement*
}

-# ##############################################################
-# CommonTime is used as a shortcut that is able to 'factor out'
-# a frequently occurring time range that a group of datum (or
-# other) elements might share, thus reducing the verbosity of the
-# XML representation. CommonTime is similar to the other NMWG time
-# stamps (from nmtime.rnc) in its potential time representations.
-#
-# It is unfortunate that it needs to be in this file and not
-# nmtime.rnc, but as it occurs outside the datum, it is here.
-#
-# Example:
-#
-# <nmwg:commonTime type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
-# duration="OPTIONAL_DURATION"
-# inclusive="OPTIONAL_INCLUSIVE_FLAG"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-# </nmwg:commonTime>
-#
-# ##############################################################
+#
##############################################################
+# CommonTime is used as a shortcut that is able to 'factor
out' 
+# a frequently occurring time range that a bunch of datum
(or 
+# other) elements might share, thus reducing complexity of
XML 
+# representation. CommonTime is similar to the other NMWG
time 
+# stamps (from nmtime.rnc) in its potential time
representations.
+#
+# Example: 
+# 
+# <nmwg:commonTime type="REQUIRED_TYPE"
value="OPTIONAL_VALUE"
+# duration="OPTIONAL_DURATION" 
+# inclusive="OPTIONAL_INCLUSIVE_FLAG"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# </nmwg:commonTime>
+# 
+#
##############################################################

-commonTime =
- element nmwg:commonTime {
+commonTime = 
+ element nmwg:commonTime {
(
Type &
(
@@ -655,60 +781,60 @@
}

-# ##############################################################
-# The datum is meant to be generic in this case because specific
-# namespace declarations should be used to better define what
-# format that datum should have.
-#
-# Example:
-#
-# <nmwg:datum ANY_ATTRIBUTE
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# </nmwg:datum>
-#
-# ##############################################################
+#
##############################################################
+# The datum is meant to be generic in this case because
specific
+# namespace declarations should be used to better define
what
+# format that datum should have.
+#
+# Example: 
+# 
+# <nmwg:datum ANY_ATTRIBUTE
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# </nmwg:datum>
+# 
+#
##############################################################

-Datum =
- element nmwg:datum {
+Datum =
+ element nmwg:datum
{
anyThing
}

-# ##############################################################
-# Common elements are defined as named patterns as they are re-
-# used several times.
-# ##############################################################
+#
##############################################################
+# Common elements are defined as named patterns as they are
re- 
+# used several times.
+#
##############################################################

-Identifier =
+Identifier =
attribute id { xsd:string }

-MetadataIdentifierRef =
+MetadataIdentifierRef =
attribute metadataIdRef { xsd:string }

-MessageIdentifierRef =
+MessageIdentifierRef =
attribute messageIdRef { xsd:string }

-Type =
+Type = 
attribute type { xsd:string }

-# ##############################################################
-# This sequence allows any element, attribute, or text (regardless
-# of name or namespace) into the document when invoked.
-# ##############################################################
+#
##############################################################
+# This sequence allows any element, attribute, or text
(regardless 
+# of name or namespace) into the document when
invoked.
+#
##############################################################

-anyElement =
- element * {
+anyElement = 
+ element * {
anyThing
}

-anyAttribute =
+anyAttribute = 
attribute * { text }

-anyThing =
+anyThing = 
(
anyElement |
anyAttribute |
@@ -716,71 +842,79 @@
)*

-# ##############################################################
-# This sequence allows any element, attribute, or text (only in the
-# NMWG namespace) into the document when invoked.
-# ##############################################################
+#
##############################################################
+# This sequence allows any element, attribute, or text (only
in the 
+# NMWG namespace) into the document when invoked.
+#
##############################################################

-anyNMWGElement =
- element nmwg:* {
+anyNMWGElement = 
+ element nmwg:* {
anyNMWGThing
}

-anyNMWGAttribute =
+anyNMWGAttribute = 
attribute * { text }

-anyNMWGThing =
+anyNMWGThing = 
(
anyNMWGElement |
anyNMWGAttribute |
text
)*
- </pre> <hr class="noprint"><h1 id="rfc.section.10"
class="np"><a href="#rfc.section.10">10.</a> Time Schema</h1> <pre>
-# ##############################################################
-#
-# File: nmtime.rnc - NMWG Time definitions
-# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z zurawski $
-# Purpose: This describes a set of time formats for
-# representing measurements.
-#
-# ##############################################################
+ </pre>
+
+<hr class="noprint">
+<h1 id="rfc.section.10" class="np">
+<a href="#rfc.section.10">10.</a> Time Schema</h1>
+
+<pre>
+#
##############################################################
+# 
+# File: nmtime.rnc - NMWG Time definitions
+# Version: $Id: nmtime.rnc 225 2007-05-02 18:16:45Z
zurawski $
+# Purpose: This describes a general time format for

+# representing measurements. It is far from
complete, 
+# and may be best represented by other
methods.
+# Reference:
http://books.xmlschemata.org/relaxng/page2.html
+# 
+#
##############################################################

-# ##############################################################
-# Namespace definitions
-# ##############################################################
-namespace nmtm = "http://ggf.org/ns/nmwg/time/2.0/";
+#
##############################################################
+# Namespace definitions
+#
##############################################################
+namespace nmtm = "http://ggf.org/ns/nmwg/time/2.0/";

-# ##############################################################
-# Regular time is attached to a specific datum instance; it is
-# essentially the same as before, but cannot have anything
-# 'inside' of it. The type can be simple, like UNIX, or it
-# could be something like timeRange or timeInterval. If this is
-# the case, we would then see the two extra time designators for
-# the start and end (or duration)
-#
-# Example:
-#
-# <nmtm:time type="REQUIRED_TYPE" value="OPTIONAL_VALUE"
-# duration="OPTIONAL_DURATION"
-# inclusive="OPTIONAL_INCLUSIVE_FLAG"
-# xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/">
-#
-# 
-#
-# 
-#
-# 
-#
-# </nmtm:time>
-#
-# ##############################################################
+#
##############################################################
+# Regular time is attached to a specific datum instance; it
is
+# essentially the same as before, but cannot have
anything
+# 'inside' of it. The type can be simple, like UNIX, or
it
+# could be something like timeRange or timeInterval. If this
is
+# the case, we would then see the two extra time designators
for
+# the start and end (or duration)
+# 
+# Example:
+# 
+# <nmtm:time type="REQUIRED_TYPE"
value="OPTIONAL_VALUE"
+# duration="OPTIONAL_DURATION" 
+# inclusive="OPTIONAL_INCLUSIVE_FLAG"
+#
xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/">
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# </nmtm:time>
+# 
+#
##############################################################

-Time =
- element nmtm:time {
+Time = 
+ element nmtm:time {
attribute type { xsd:string } &
(
TimeStamp |
@@ -794,95 +928,105 @@
)
}

-TimeStamp =
+TimeStamp = 
(
attribute value { xsd:string } |
- element nmtm:value { xsd:string }
+ element nmtm:value { xsd:string }
)

-Duration =
+Duration =
attribute duration { xsd:string }

-TimeContent =
+TimeContent = 
attribute type { text } &
attribute inclusive { text }? &
TimeStamp

-StartTime =
- element nmtm:start {
+StartTime = 
+ element nmtm:start
{
TimeContent
}

-EndTime =
- element nmtm:end {
+EndTime = 
+ element nmtm:end {
TimeContent
}
- </pre> <hr class="noprint"><h1 id="rfc.section.11"
class="np"><a href="#rfc.section.11">11.</a> Topology Schema</h1> <pre>
-# ##############################################################
-#
-# File: nmtopo.rnc - Schema to describe topological
-# elements.
-# Version: $Id: nmtopo.rnc 209 2007-02-15 17:20:25Z zurawski $
-#
-# ##############################################################
+ </pre>
+
+<hr class="noprint">
+<h1 id="rfc.section.11" class="np">
+<a href="#rfc.section.11">11.</a> Topology Schema</h1>
+
+<pre>
+#
##############################################################
+# 
+# File: nmtopo.rnc - Schema to describe topological

+# features to be used in subject

+# elements.
+# Version: $Id: nmtopo.rnc 209 2007-02-15 17:20:25Z
zurawski $
+# Purpose: This file lays out some major network
topologies
+# used in measurement. 
+# Reference:
http://books.xmlschemata.org/relaxng/page2.html
+# 
+#
##############################################################

-# ##############################################################
-# Namespace definitions
-# ##############################################################
-namespace nmwgtopo = "http://ggf.org/ns/nmwg/topology/2.0/";
+#
##############################################################
+# Namespace definitions
+#
##############################################################
+namespace nmwgtopo =
"http://ggf.org/ns/nmwg/topology/2.0/";

-# ##############################################################
-# Covers the basic point to point measurement situation. The two
-# points are a source and destination; may contain information
-# such as hostname or ip address, and port number when applicable.
-#
-# Example:
-#
-# <nmwgtopo:endPointPair
-# xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
-#
-# <nmwgtopo:src type="REQUIRED_TYPE" value="REQUIRED_VALUE"
-# port="OPTIONAL_PORT"/>
-#
-# <nmwgtopo:dst type="REQUIRED_TYPE" value="REQUIRED_VALUE"
-# port="OPTIONAL_PORT"/>
-#
-# </nmwgtopo:endPointPair>
-#
-# ##############################################################
+#
##############################################################
+# Covers the basic point to point measurement situation.
The two 
+# points are a source and destination; may contain
information 
+# such as hostname or ip address, and port number when
applicable.
+# 
+# Example:
+# 
+# <nmwgtopo:endPointPair 
+#
xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
+# 
+# <nmwgtopo:src type="REQUIRED_TYPE"
value="REQUIRED_VALUE" 
+# port="OPTIONAL_PORT"/>
+# 
+# <nmwgtopo:dst type="REQUIRED_TYPE"
value="REQUIRED_VALUE" 
+# port="OPTIONAL_PORT"/>
+# 
+# </nmwgtopo:endPointPair>
+# 
+#
##############################################################

-EndpointPair =
- element nmwgtopo:endPointPair {
+EndpointPair = 
+ element nmwgtopo:endPointPair {
EndpointPairContent
}

-EndpointPairContent =
- element nmwgtopo:src {
+EndpointPairContent =
+ element nmwgtopo:src {
EndpointContent
} &
- element nmwgtopo:dst {
+ element nmwgtopo:dst {
EndpointContent
}

-# ##############################################################
-# Similar to above, from one point only.
-#
-# Example:
-#
-# <nmwgtopo:endPoint type="REQUIRED_TYPE" value="REQUIRED_VALUE"
-# port="OPTIONAL_PORT"/>
-#
-# ##############################################################
+#
##############################################################
+# Similar to above, from one point only.
+# 
+# Example:
+# 
+# <nmwgtopo:endPoint type="REQUIRED_TYPE"
value="REQUIRED_VALUE" 
+# port="OPTIONAL_PORT"/>
+# 
+#
##############################################################

-Endpoint =
- element nmwgtopo:endPoint {
+Endpoint = 
+ element nmwgtopo:endPoint {
EndpointContent
}

-EndpointContent =
+EndpointContent = 
(
attribute value { xsd:string } |
text
@@ -891,125 +1035,160 @@
attribute port { xsd:string }?

-# ##############################################################
-# When looking at network utilization numbers (from a router or
-# related software) there is a different set of applicable
-# information
-#
-# Example:
-#
-# <nmwgtopo:interface
xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
-#
-# <nmwgtopo:ipAddress type='REQUIRED_TYPE'> TEXT
</nmwgtopo:ipAddress>
-#
-# <nmwgtopo:hostName> TEXT </nmwgtopo:hostName>
-#
-# <nmwgtopo:ifName> TEXT </nmwgtopo:ifName>
-#
-# <nmwgtopo:ifDescription> TEXT </nmwgtopo:ifDescription>
-#
-# <nmwgtopo:ifAddress type='REQUIRED_TYPE'> TEXT
</nmwgtopo:ifAddress>
-#
-# <nmwgtopo:ifHostName> TEXT </nmwgtopo:ifHostName>
-#
-# <nmwgtopo:ifIndex> TEXT </nmwgtopo:ifIndex>
-#
-# <nmwgtopo:type> TEXT </nmwgtopo:type>
-#
-# <nmwgtopo:direction> TEXT </nmwgtopo:direction>
-#
-# <nmwgtopo:authRealm> TEXT </nmwgtopo:authRealm>
-#
-# <nmwgtopo:classOfService> TEXT </nmwgtopo:classOfService>
-#
-# <nmwgtopo:capacity> TEXT </nmwgtopo:capacity>
-#
-# </nmwgtopo:interface>
-#
-# ##############################################################
+#
##############################################################
+# When looking at network utilization numbers (from a router
or 
+# related software) there is a different set of applicable

+# information
+# 
+# Example:
+# 
+# <nmwgtopo:interface
xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
+# 
+# <nmwgtopo:ipAddress type='REQUIRED_TYPE'> TEXT
</nmwgtopo:ipAddress>
+# 
+# <nmwgtopo:hostName> TEXT
</nmwgtopo:hostName>
+# 
+# <nmwgtopo:ifName> TEXT
</nmwgtopo:ifName>
+# 
+# <nmwgtopo:ifDescription> TEXT
</nmwgtopo:ifDescription>
+# 
+# <nmwgtopo:ifAddress type='REQUIRED_TYPE'> TEXT
</nmwgtopo:ifAddress>
+# 
+# <nmwgtopo:ifHostName> TEXT
</nmwgtopo:ifHostName>
+# 
+# <nmwgtopo:ifIndex> TEXT
</nmwgtopo:ifIndex>
+# 
+# <nmwgtopo:type> TEXT </nmwgtopo:type>
+# 
+# <nmwgtopo:direction> TEXT
</nmwgtopo:direction>
+# 
+# <nmwgtopo:authRealm> TEXT
</nmwgtopo:authRealm>
+# 
+# <nmwgtopo:classOfService> TEXT
</nmwgtopo:classOfService>
+# 
+# <nmwgtopo:capacity> TEXT
</nmwgtopo:capacity>
+# 
+# </nmwgtopo:interface>
+# 
+#
##############################################################

-Interface =
- element nmwgtopo:interface {
+Interface = 
+ element nmwgtopo:interface {
InterfaceContent
}

-InterfaceContent =
- element nmwgtopo:ipAddress {
+InterfaceContent = 
+ element nmwgtopo:ipAddress {
Address
}? &
- element nmwgtopo:hostName { xsd:string }? &
- element nmwgtopo:ifName { xsd:string }? &
- element nmwgtopo:ifDescription { xsd:string }? &
- element nmwgtopo:ifAddress {
+ element nmwgtopo:hostName { xsd:string }? &
+ element nmwgtopo:ifName { xsd:string }? &
+ element nmwgtopo:ifDescription { xsd:string }? &
+ element nmwgtopo:ifAddress {
Address
}? &
- element nmwgtopo:ifHostName { xsd:string }? &
- element nmwgtopo:ifIndex { xsd:string }? &
- element nmwgtopo:type { xsd:string }? &
- element nmwgtopo:direction { xsd:string }? &
- element nmwgtopo:authRealm { xsd:string }? &
- element nmwgtopo:classOfService { xsd:string }? &
- element nmwgtopo:capacity { xsd:string }?
+ element nmwgtopo:ifHostName { xsd:string }? &
+ element nmwgtopo:ifIndex { xsd:string }? &
+ element nmwgtopo:type { xsd:string }? &
+ element nmwgtopo:direction { xsd:string }? &
+ element nmwgtopo:authRealm { xsd:string }? &
+ element nmwgtopo:classOfService { xsd:string }? &
+ element nmwgtopo:capacity { xsd:string }?

-Address =
+Address = 
(
attribute value { xsd:string } |
text
) &
attribute type { xsd:string }

- </pre> <hr class="noprint"><h1 id="rfc.section.12"
class="np"><a href="#rfc.section.12">12.</a> Examples</h1>This section includes examples of network
measurements rendered in our schema. These examples are not intended to be
normative, although at this time of this writing, they are in use.<h2
id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a> Schema for
ping</h2> <pre>
+ </pre>
+
+<hr class="noprint">
+<h1 id="rfc.section.12" class="np">
+<a href="#rfc.section.12">12.</a> Examples</h1>
+This section includes examples of network
measurements rendered in our schema. These examples are not intended to be
normative, although at this time of this writing, they are in use.
+<h2 id="rfc.section.12.1">
+<a href="#rfc.section.12.1">12.1</a> Schema for ping</h2>
+
+<pre>

-# ##############################################################
-#
-# File: ping.rnc - Specialized schema for the ping
-# tool
-# Version: $Id: ping.rnc 205 2007-02-05 17:33:00Z zurawski $
-# Purpose: Defines elements to be used in the representation
-# of ping measurements.
-#
-# ##############################################################
+#
##############################################################
+# 
+# File: ping.rnc - Specialized schema for the ping

+# tool
+# Version: $Id: ping.rnc 205 2007-02-05 17:33:00Z
zurawski $
+# Purpose: Describes specific elements to be used in
the
+# representation and handling of ping
+# measurements.
+# Reference:
http://books.xmlschemata.org/relaxng/page2.html
+# 
+#
##############################################################

-# ##############################################################
-# Namespace definitions
-# ##############################################################
-namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
-namespace ping = "http://ggf.org/ns/nmwg/tools/ping/2.0/";
-namespace nmwgr = "http://ggf.org/ns/nmwg/result/2.0/";
+#
##############################################################
+# Namespace definitions
+#
##############################################################
+namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
+namespace ping =
"http://ggf.org/ns/nmwg/tools/ping/2.0/";
+namespace nmwgr =
"http://ggf.org/ns/nmwg/result/2.0/";

-# ##############################################################
-# Include additional functionality from other files
-# ##############################################################
-include "nmtopo.rnc"
-include "nmtopo_ver3.rnc"
-include "result.rnc"
-include "nmbase.rnc" {
- Metadata |= PingMetadata
- Data |= PingData
+#
##############################################################
+# Include additional functionality from other files
+#
##############################################################
+include "nmtopo.rnc"
+include "nmtopo_ver3.rnc"
+include "result.rnc"
+include "nmbase.rnc" {
+ Metadata |= PingMetadata
+ Data |= PingData 
}

-# ##############################################################
-# Metadata
-# ##############################################################
+#
##############################################################
+# Metadata is the 'data' that describes physical
measurements. 
+# Metadata can be something such as a physical address, or

+# a geographical location; any form of static, re-usable

+# designation. It is important to note that the
subject
+# namespace and parameters namespace MUST match (or the
parameters
+# can be a generic NMWG) or bad things will occur.
+#
+# Example: 
+# 
+# <nmwg:metadata id="REQUIRED_ID" 
+# metadataIdRef="OPTIONAL_REFERENCE_ID"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# 
+#
+# 
+# 
+# 
+# 
+#  
+#
+# </nmwg:metadata>
+# 
+#
##############################################################

-PingMetadata =
- element nmwg:metadata {
+PingMetadata = 
+ element nmwg:metadata {
Identifier &
MetadataIdentifierRef? &
PingMetadataContent
}

-PingMetadataBlock =
+PingMetadataBlock = 
PingSubject? &
(
PingParameters |
Parameters
)?

-PingMetadataContent =
+PingMetadataContent = 
(
PingMetadataBlock |
FilterMetadataBlock
@@ -1018,32 +1197,32 @@
Key?

-# ##############################################################
-# Redefined ping subject allows only an endPointPair, and the
-# two id attributes.
-#
-# Example:
-#
-# <ping:subject id="REQUIRED_ID"
-# metadataIdRef="OPTIONAL_REFERENCE_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
-#
-# <nmwgtopo:endPointPair
xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
-#
-# <nmwgtopo:src type="REQUIRED_TYPE" value="REQUIRED_VALUE"
-# port="OPTIONAL_PORT"/>
-#
-# <nmwgtopo:dst type="REQUIRED_TYPE" value="REQUIRED_VALUE"
-# port="OPTIONAL_PORT"/>
-#
-# </nmwgtopo:endPointPair>
-#
-# </ping:subject>
-#
-# ##############################################################
+#
##############################################################
+# Redefined ping subject allows only an endPointPair, and
the
+# two id attributes. 
+#
+# Example: 
+# 
+# <ping:subject id="REQUIRED_ID" 
+# metadataIdRef="OPTIONAL_REFERENCE_ID"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
+# 
+# <nmwgtopo:endPointPair
xmlns:nmwgtopo="http://ggf.org/ns/nmwg/topology/2.0/">
+# 
+# <nmwgtopo:src type="REQUIRED_TYPE"
value="REQUIRED_VALUE" 
+# port="OPTIONAL_PORT"/>
+# 
+# <nmwgtopo:dst type="REQUIRED_TYPE"
value="REQUIRED_VALUE" 
+# port="OPTIONAL_PORT"/>
+# 
+# </nmwgtopo:endPointPair>
+# 
+# </ping:subject>
+#
+#
##############################################################

-PingSubject =
- element ping:subject {
+PingSubject =
+ element ping:subject {
Identifier &
MetadataIdentifierRef? &
(
@@ -1053,37 +1232,37 @@
}

-# ##############################################################
-# This is simply the regular method of doing parameters with an
-# enumeration to limit what 'names' are accepted and an outer
-# ping: namespace for the parameters.
-#
-# Example:
-#
-# <ping:parameters id="REQUIRED_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
-#
-# <nmwg:parameter name="REQUIRED_ENUM_NAME" value="OPTIONAL_VALUE"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# </nmwg:parameter>
-#
-# 
-#
-# </ping:parameters>
-#
-# ##############################################################
+#
##############################################################
+# This is simply the regular method of doing parameters with
an
+# enumeration to limit what 'names' are accepted and an
outer
+# ping: namespace for the parameters.
+#
+# Example: 
+# 
+# <ping:parameters id="REQUIRED_ID" 
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
+# 
+# <nmwg:parameter name="REQUIRED_ENUM_NAME"
value="OPTIONAL_VALUE"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# </nmwg:parameter>
+# 
+# 
+# 
+# </ping:parameters>
+# 
+#
##############################################################

-PingParameters =
- element ping:parameters {
+PingParameters =
+ element ping:parameters {
Identifier &
PingParameter+
}

-PingParameter =
- element nmwg:parameter {
+PingParameter = 
+ element nmwg:parameter {
attribute name { "count" | "interval" | "deadline" |
"packetSize" | "ttl" | "arguments" |
"valueUnits" | "numBytes" |
@@ -1095,43 +1274,43 @@
}

-# ##############################################################
-# The data block is complex, and has the potential to contain
-# many things. The data block can be used to return a metadata
-# block from a request, commonTime or datum elements, keys,
-# or something that we have perhaps not defined as of yet.
-#
-# Example:
-#
-# <nmwg:data id="REQUIRED_ID"
-# metadataIdRef="OPTIONAL_REFERENCE_ID"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# 
-#
-# </nmwg:data>
-#
-# ##############################################################
+#
##############################################################
+# The data block is complex, and has the potential to
contain
+# many things. The data block can be used to return a
metadata
+# block from a request, commonTime or datum elements, keys,

+# or something that we have perhaps not defined as of yet.

+#
+# Example: 
+# 
+# <nmwg:data id="REQUIRED_ID" 
+# metadataIdRef="OPTIONAL_REFERENCE_ID" 
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# 
+#
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# </nmwg:data>
+# 
+#
##############################################################

-PingData =
- element nmwg:data {
+PingData =
+ element nmwg:data {
Identifier &
MetadataIdentifierRef? &
(
@@ -1155,12 +1334,35 @@
}

-# ##############################################################
-# CommonTime
-# ##############################################################
+#
##############################################################
+# CommonTime is used a a shortcut able to 'factor out' a
frequently
+# occurring time range that a bunch of datum (or other)
elements
+# might share, thus reducing complexity of XML
representation. 
+# CommonTime is similar to the other NMWG time stamps (from

+# nmtime.rnc) in its potential time representations.
+#
+# Example: 
+# 
+# <nmwg:commonTime type="REQUIRED_TYPE"
value="OPTIONAL_VALUE"
+# duration="OPTIONAL_DURATION" 
+# inclusive="OPTIONAL_INCLUSIVE_FLAG"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/">
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# 
+# </nmwg:commonTime>
+# 
+#
##############################################################

-PingCommonTime =
- element nmwg:commonTime {
+PingCommonTime = 
+ element nmwg:commonTime {
Type &
(
TimeStamp |
@@ -1179,30 +1381,30 @@
}

-# ##############################################################
-# These are the basic elements we would expect to see in the
-# specific ping datum.
-#
-# Example:
-#
-# <ping:datum value="REQUIRED_VALUE"
-# valueUnits="OPTIONAL_VALUE_UNITS"
-# numBytes="OPTIONAL_NUM_BYTES"
-# numBytesUnits="OPTIONAL_NUM_BYTES_UNITS"
-# seqNum="OPTIONAL_SEQ_NUM"
-# ttl="OPTIONAL_TTL"
-# timeType="OPTIONAL_TIME_TYPE"
-# timeValue="OPTIONAL_TIME_VALUE"
-# xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
-#
-# 
-#
-# </ping:datum>
-#
-# ##############################################################
+#
##############################################################
+# These are the basic elements we would expect to see in the

+# specific ping datum.
+#
+# Example: 
+# 
+# <ping:datum value="REQUIRED_VALUE"
+# valueUnits="OPTIONAL_VALUE_UNITS"
+# numBytes="OPTIONAL_NUM_BYTES"
+#
numBytesUnits="OPTIONAL_NUM_BYTES_UNITS"
+# seqNum="OPTIONAL_SEQ_NUM"
+# ttl="OPTIONAL_TTL"
+# timeType="OPTIONAL_TIME_TYPE"
+# timeValue="OPTIONAL_TIME_VALUE"
+#
xmlns:nmwg="http://ggf.org/ns/nmwg/tools/ping/2.0/">
+# 
+# 
+# 
+# </ping:datum>
+# 
+#
##############################################################

-PingDatum =
- element ping:datum {
+PingDatum =
+ element ping:datum
{
attribute value { xsd:float } &
attribute valueUnits { xsd:string }? &
attribute numBytes { xsd:int }? &
@@ -1218,15 +1420,68 @@
)?
}

- </pre> <h2 id="rfc.section.12.2"><a
href="#rfc.section.12.2">12.2</a> Instance document for ping</h2> <pre>

- </pre> <hr class="noprint"><h1 id="rfc.section.13"
class="np"><a href="#rfc.section.13">13.</a> Security Concerns</h1>There are important security concerns associated with
the generation and distribution of network measurement information. For
example, ISPs frequently consider network configuration and performance
information to be proprietary. Furthermore, observing traffic, and, in
particular, collecting packet headers, is frequently considered a violation
of the presumption of privacy on the network. Systems that collect the
measurements described here are sometimes regarded as invasive, and, indeed,
poorly designed or configured monitoring tools can consume a disproportionate
amount of network bandwidth. Port blocking, protocol blocking, and traffic
shaping can impact many measurement tools. Tools, such as traceroute, that
send UDP probes to increasing port numbers can appear to be port scans and
raise security alerts.We do not address those concerns in this document, but
implementers are encouraged to consider the security implications of
generating and distributing measurement information. While distribution of
end-to-end application-level measurements is generally accepted, measurements
that identify individual users or consume noticeable amounts of resources
should be taken carefully, and the distribution of information to other sites
that cannot be obtained readily by other users at those sites should be
considered carefully.<hr class="noprint"><h1 id="rfc.section.14"
class="np"><a href="#rfc.section.14">14.</a> Appendices</h1><h2
id="rfc.section.14.1"><a
href="#rfc.section.14.1">14.1</a> Acknowledgements</h2>We gratefully acknowledge the contributions of:
Jeff Boote, Eric Boyd, Mark Leese, Dan Gunter, Richard Hughes-Jones and Jason
Zurawski and (who else??) the other members of the Network Measurements
Working Group.<h1
class="np" id="rfc.references"><a href="#rfc.section.15">15!
.</a> Re
ferences</h1><table summary="References" border="0" cellpadding="2"><tr><td
class="topnowrap">[1]</td><td class="top">Zurawski,
J., Swany, M., and D. Gunter, “A Scalable Framework for Representation
and Exchange of
+ </pre>
+
+<h2 id="rfc.section.12.2">
+<a href="#rfc.section.12.2">12.2</a> Instance document for ping</h2>
+
+<pre>

+ </pre>
+
+<hr class="noprint">
+<h1 id="rfc.section.13" class="np">
+<a href="#rfc.section.13">13.</a> Security Concerns</h1>
+There are important security concerns associated
with the generation and distribution of network measurement information. For
example, ISPs frequently consider network configuration and performance
information to be proprietary. Furthermore, observing traffic, and, in
particular, collecting packet headers, is frequently considered a violation
of the presumption of privacy on the network. Systems that collect the
measurements described here are sometimes regarded as invasive, and, indeed,
poorly designed or configured monitoring tools can consume a disproportionate
amount of network bandwidth. Port blocking, protocol blocking, and traffic
shaping can impact many measurement tools. Tools, such as traceroute, that
send UDP probes to increasing port numbers can appear to be port scans and
raise security alerts.
+We do not address those concerns in this
document, but implementers are encouraged to consider the security
implications of generating and distributing measurement information. While
distribution of end-to-end application-level measurements is generally
accepted, measurements that identify individual users or consume noticeable
amounts of resources should be taken carefully, and the distribution of
information to other sites that cannot be obtained readily by other users at
those sites should be considered carefully.
+<hr class="noprint">
+<h1 id="rfc.section.14" class="np">
+<a href="#rfc.section.14">14.</a> Appendices</h1>
+<h2 id="rfc.section.14.1">
+<a href="#rfc.section.14.1">14.1</a> Acknowledgements</h2>
+We gratefully acknowledge the contributions of:
Jeff Boote, Eric Boyd, Mark Leese, Dan Gunter, Richard Hughes-Jones and Jason
Zurawski and (who else??) the other members of the Network Measurements
Working Group.
+<h1 class="np" id="rfc.references">
+<a href="#rfc.section.15">15.</a> References</h1>
+<table summary="References" border="0" cellpadding="2">
+<tr>
+<td class="topnowrap">
+[1]
+</td>
+<td class="top">Zurawski, J., Swany, M., and D. Gunter, “A Scalable
Framework for Representation and Exchange of
Network Measurements”, In Proceedings of 2nd
International IEEE/Create-Net
Conference on Testbeds and Research Infrastructures for the
Development of Networks and Communities (Tridentcom
- 2006).</td></tr></table><hr class="noprint"><h1 id="rfc.authors"
class="np">Author's Address</h1><address class="vcard">D. Martin Swany
+ 2006).</td>
+</tr>
+</table>
+<hr class="noprint">
+<h1 id="rfc.authors" class="np">Author's Address</h1>
+<address class="vcard">
+
+D. Martin Swany
(Editor)
- SwanyD. Martin
+ 
+Swany
+D. Martin
+
+
+
University of Delaware
Department of Computer and Information Sciences
Newark, DE 19716
- </address><h1><a id="rfc.copyright" href="#rfc.copyright">Full
Copyright Statement</a></h1>Copyright � The Open Grid Forum (2007). All
Rights Reserved.This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included on
all such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the OGF or other organizations, except as needed for the
purpose of developing Grid Recommendations in which case the procedures for
copyrights defined in the OGF Document process must be followed, or as
required to translate it into languages other than English.The limited
permissions granted above
are perpetual and will not be revoked by the OGF or its successors or
assignees.This document and the information contained herein is
provided on an “As Is” basis and the OGF disclaims all
warranties, express or implied, including but not limited to any warranty
that the use of the information herein will not infringe any rights or any
implied warranties of merchantability or fitness for a particular
purpose.<hr class="noprint"><h1 class="np"><a id="rfc.ipr"
href="#rfc.ipr">Intellectual Property</a></h1>The OGF takes no position
regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any license
under such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. Copies of claims of
rights made available for publication and any assurance
s of licenses to be made available, or the result of an atte!
mpt made
to obtain a general license or permission for the use of such proprietary
rights by implementers or users of this specification can be obtained from
the OGF Secretariat.The OGF invites any interested party to bring to
its attention any copyrights, patents or patent applications, or other
proprietary rights, which may cover technology that may be required to
practice this recommendation. Please address the information to the OGF
Executive Director.</body></html>
\ No newline at end of file
+ 
+</address>
+<h1>
+<a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a>
+</h1>
+Copyright � The Open Grid Forum (2007). All Rights Reserved.
+This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or references
to the OGF or other organizations, except as needed for the purpose of
developing Grid Recommendations in which case the procedures for copyrights
defined in the OGF Document process must be followed, or as required to
translate it into languages other than English.
+The limited permissions granted above are perpetual and will not be
revoked by the OGF or its successors or assignees.
+This document and the information contained herein is provided on an
“As Is” basis and the OGF disclaims all warranties, express or
implied, including but not limited to any warranty that the use of the
information herein will not infringe any rights or any implied warranties of
merchantability or fitness for a particular purpose.
+<hr class="noprint">
+<h1 class="np">
+<a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a>
+</h1>
+The OGF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain to the
implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be
available; neither does it represent that it has made any effort to identify
any such rights. Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the OGF Secretariat.
+The OGF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights,
which may cover technology that may be required to practice this
recommendation. Please address the information to the OGF Executive
Director.
+</body>
+</html

Modified: trunk/nmwg/doc/nm-schema-base/nm-schema-base.pdf
===================================================================
(Binary files differ)

Modified: trunk/nmwg/doc/nm-schema-base/post.pl
===================================================================
--- trunk/nmwg/doc/nm-schema-base/post.pl 2007-05-07 13:12:03 UTC (rev
230)
+++ trunk/nmwg/doc/nm-schema-base/post.pl 2007-05-07 13:28:53 UTC (rev
231)
@@ -48,51 +48,51 @@
my $found = 0;
my $keyword = "";
foreach my $k (@keywords) {
- foreach my $t (@tokens) {
- if($k eq $t) {
- $found = 1;
- $keyword = $k;
- last;
- }
+ foreach my $t (@tokens) {
+ if($k eq $t) {
+ $found = 1;
+ $keyword = $k;
+ last;
+ }
}
}

if($found) {
- # we found a token, print it and see if we
- # need to highlight the next word
- print $prefix , "" , $tokens[0] , " ";
+ # we found a token, print it and see if we
+ # need to highlight the next word
+ print $prefix , "" , $tokens[0] , " ";

- if($#tokens > 1) {
+ if($#tokens > 1) {
my $found2 = 0;
foreach my $k (@keywords_next) {
- if($k eq $keyword) {
- $found2 = 1;
- last;
- }
+ if($k eq $keyword) {
+ $found2 = 1;
+ last;
+ }
}

- if($found2) {
+ if($found2) {

- # we can highlight the next word
- print "" , $tokens[1] , " ";
+ # we can highlight the next word
+ print "" , $tokens[1] , " ";

for(my $x = 2; $x <= $#tokens; $x++) {
- print $tokens[$x] , " ";
- }
- }
- else {
+ print $tokens[$x] , " ";
+ }
+ }
+ else {
for(my $x = 1; $x <= $#tokens; $x++) {
- print $tokens[$x] , " ";
- }
- }
+ print $tokens[$x] , " ";
+ }
+ }

- }
- else {
+ }
+ else {
for(my $x = 1; $x <= $#tokens; $x++) {
- print $tokens[$x] , " ";
- }
- }
+ print $tokens[$x] , " ";
+ }
+ }

- print "\n";
+ print "\n";
}
else {
print $_ , "\n";
@@ -100,6 +100,6 @@
}
}
else {
- print $_;
+ print $_ , "\n";
}
}

nmwg: r231 - trunk/nmwg/doc/nm-schema-base, svnlog, 05/07/2007

List archive

nmwg: r231 - trunk/nmwg/doc/nm-schema-base