perfsonar development work

[David Schmitz <>]

Hi all,

> HI David,
> 
> could you send example messages (or their addresses) of those 3 proposals.
Here some examples and corresponding rnc schema:

first approach of Jason:
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/rnc/errors.rnc
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/rnc/discards.rnc
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/discards
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors.xml

second approach of Jason (snmp unified):
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/rnc/snmp.rnc
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/snmp
http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/snmp.xml


See attached files (frames.rnc and frames.xml) for my own proposal.


Best Regards,
David

> 
> Roman
> 
> 
> 
> David Schmitz wrote:
> > Hi all,
> >
> > the development of the snmp ifError/ifDiscards MA will start rather soon
> > (next week) and there are still issues to discuss.
> > As probably not all people had time to follow the discussion in the
> > mailing list recently, I give a short summary about the schema being
> > developed for this new type of MA:
> >
> > In general, this type of MA will be similar to the utilization MA,
> > but it will support multiple metrics:
> > There are two new snmp metrics to support with this new type of MA
> > at the moment: ifErrors and ifDiscards (frame drops),
> > more metrics may be added later.
> >
> > Jason has proposed 2 different possibilities for the new schema,
> > while I myself simultaneously proposed another one:
> >
> > Jason's first solution is very similar to the existing schema for the
> > utilization MA.
> > Here, in fact, for both new metrics (errors and discards) separate
> > schemas and namespaces (each similar to the utilization schema) are used.
> > The advantage of this possibility is that the adaptation from the existing
> > utilization MA to the new MA is very easy, and not much changes should
> > be required in the MA code.
> > As the developing of the new MA will start next week very soon, we should
> > using
> > this solution in the beginning.
> >
> > Jason's second solution is a unified solution covering any SNMP metric, 
> > i.e.
> > utilization, errors, drops, and new ones to come in the future.
> > This single schema uses different event types for distinguishing
> > between the different metrics.
> > Above all, it supports a wildcard eventType covering all available 
> > metrics.
> > The advantage of this schema is that it allows to fetch the data for
> > multiple metrics
> > of a single subject (e.g. an ip link) without specifying the subject twice
> > in the request.
> > So it probably allows for a better performance.
> > Further, the integration of new SNMP metrics is possible.
> > This solution is of course more complex than the first one and MA Service
> > developers will have to check the effort to adapt their services to this 
> > new
> > schema.
> > The openness for the future of this unified approach should be
> > discussed, i.e. if it really is sufficient for all new metrics to come.
> > We should not have to change the existing schemas too often.
> > Specifically, we have to take care of the compability with the existing
> > utilization schema.
> >
> > Additionally, I myself proposed a schema for error and drops which
> > lies more or less between Jason's proposals.
> > My idea was to have a single schema for the two new metrics.
> > As Jason already addressed this issue with his second approach (even
> > integrating utilization) and he is more involved in NMWG schema 
> > development,
> > it's probably better to
> > start with his proposal instead of my own.
> >
> >
> > Best Regards,
> > David
> >
> >   
> > > Nicolas Simar wrote:
> > >     
> > > > Jason Zurawski wrote:
> > > >       
> > > > > David;
> > > > >
> > > > >         
> > > > > > Jason, from your point of view, which of the schema proposals 
> > > > > > could
> > > > > > be
> > > > > > easily made ready for immediate use next week?
> > > > > >
> > > > > >   
> > > > > >           
> > > > > In my opinion we should proceed with the method that best maps
> > > > > reality,
> > > > > not which is fastest to implement.  It would be great to hear 
> > > > > comments
> > > > > on
> > > > > both methods from various interested parties soon (and if its next
> > > > > week
> > > > > you are looking to implement, comments need to come *very* soon).
> > > > >         
> > > > I guess that the interested parties are:
> > > > - the visualisation developers: Nina/Vedrin (psUI), David/Andreas 
> > > > (CNM),
> > > > Daniel(visualperfSONAR)
> > > > - the web-service developers: Roman (RRD), Jeff/Jason (SNMP MP)
> > > >       
> > > I suspect it does not matter that much for the visualization developers.
> > > They
> > > will need to start looking for additional schema/variables no matter 
> > > what.
> > > And, I suspect something similar to the current structure should not be
> > > difficult for them. I believe Jason's proposal is much more similar to 
> > > the
> > > current structure than David's. (I do understand the desire to retrieve
> > > multiple data types within a single data. Especially from a 
> > > visualization
> > > point of view. However, I think this would be a complex thing to work 
> > > into
> > > current services. The 'typed' datum is a completely new concept.)
> > >
> > > For the service developers, I believe the main issue is how difficult it
> > > is to
> > > extend the store to support multiple eventTypes. Multiples, no matter 
> > > the
> > > namespace add some complexity.
> > >
> > > However, I think we can postpone some of the complexity (at least from 
> > > the
> > > perspective of the RRD MA) if we first support the errors/discards from
> > > the
> > > characteristic namespace. This will reduce the number of nmwg classes 
> > > that
> > > Roman needs to create in support of this. (And, they end up being near
> > > duplicates to the existing 'utilization' class - so it should be 
> > > trivial.)
> > >
> > > The SNMP MP implementation does not have complexity in this space 
> > > because
> > > it
> > > is using DOM for this - additional namespaces are just handled at the
> > > query
> > > level - there is no 'marshalling' to worry about. However, as I said - 
> > > the
> > > multiple eventTypes are still an issue.
> > >
> > > Perhaps we should start the discussion with evaluating this part (how do
> > > deal
> > > with multiple eventTypes) of Jason's proposal. (I like it, but I was his
> > > sounding board for ideas...) It would be far better if others commented.
> > >
> > > jeff
> > >
> > >
> > >     
> > > > Nicolas
> > > >
> > > >       
> > > > > > Do you foresee an easy way starting with only the basic
> > > > > > features necessary (for next week), while not much complicating 
> > > > > > the
> > > > > > later integration of more complex features (e.g. tool namespace
> > > > > > snmp)?
> > > > > >   
> > > > > >           
> > > > > Any or all of the standard we choose can be implemented to start 
> > > > > with,
> > > > > as
> > > > > long as everything is fully implemented in the end.  in my opinion
> > > > > keeping
> > > > > things 'similar' to the characteristic style (similar to 
> > > > > utilization)
> > > > > is
> > > > > the fastest route to start with (both for getting comments on this
> > > > > list
> > > > > and for allowing service developers to get started).  No matter 
> > > > > which
> > > > > method we choose it is imperative that extension be possible in the
> > > > > future
> > > > > (i.e. to the SNMP namespace, etc.).
> > > > >
> > > > > -jason
> > > > >
> > > > >         
> >
> >   
> 

-- 

David Schmitz

Boltzmannstraße 1, 85748 Garching
Telefon:   +49 89 35831-8765
Fax:       +49 89 35831-9700
Leibniz-Rechenzentrum, Germany
Mail:  


<?xml version="1.0" encoding="UTF-8"?>
<nmwg:message type="store" 
              xmlns="http://ggf.org/ns/nmwg/base/2.0/";
              xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
              xmlns:netfram="http://ggf.org/ns/nmwg/characteristic/framemetric/2.0/";
              xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
              xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/";
              xmlns:nmwgtopo3="http://ggf.org/ns/nmwg/topology/base/3.0/";
              xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/";
              xmlns:average="http://ggf.org/ns/nmwg/ops/average/2.0/";
              xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>

  <!-- Metadata using original topology schema -->              

  <nmwg:metadata id="iumeta1">
    <netfram:subject id="iusub1">
      <nmwgt:interface>
        <nmwgt:ipAddress type="v4">10.10.11.1</nmwgt:ipAddress>
        <nmwgt:hostName>dreadnought</nmwgt:hostName>
        <nmwgt:ifName>eth0</nmwgt:ifName>
        <nmwgt:ifDescription>gigE</nmwgt:ifDescription>
        <nmwgt:ifAddress type="ipv4">128.4.133.163</nmwgt:ifAddress>
        <nmwgt:ifIndex>0</nmwgt:ifIndex>
        <nmwgt:type>eth0</nmwgt:type>        
        <nmwgt:authRealm>someauth</nmwgt:authRealm>
<!--
        goes back to queueing strategy, could be
        more specifications?
        
        <classOfService>Best Effort</nmwgt:classOfService>
        <classOfService>Scavenger</nmwgt:classOfService>
        <classOfService>OSCARS</nmwgt:classOfService>
        <classOfService>All</nmwgt:classOfService>                                                
-->                                
        <nmwgt:classOfService>All</nmwgt:classOfService>                
<!--
        Can specify this up here, or use seperate metadata chains
        to describe.
        -->

        <nmwgt:direction>*</nmwgt:direction>
        <nmwgt:direction>in</nmwgt:direction>
        <nmwgt:direction>out</nmwgt:direction>        
 
      </nmwgt:interface>
    </netfram:subject>

    <!-- some alternatives: -->
    <netfram:eventType>http://ggf.org/ns/nmwg/characteristic/frames/2.0/any</netfram:eventType>
    <netfram:eventType>http://ggf.org/ns/nmwg/characteristic/frames/2.0/ifDiscards</netfram:eventType>
    <netfram:eventType>http://ggf.org/ns/nmwg/characteristic/frames/2.0/ifErrors</netfram:eventType>

    <!-- Any subsumes all available (frames) metrics, i.e. at the moment ifDiscards and ifErrors -->
    <!-- nmwgt:direction + netfram::eventType together determine which 
         actual frame counters are selected:

         e.g. direction=* + eventType=.../ifDiscards: ifInDiscards + ifOutDiscards selected,
         e.g. direction=in + eventType=.../any: ifInDiscards + ifInErrors selected,
         e.g. direction=out + eventType=.../ifErrors: ifOutErrors selected,

         so it is possible to get all available (frame) metrics for an ipAddress at once
    -->

    </netfram:eventType>
    
    <netfram:parameters id="param1">
      <nmwg:parameter name="interval">1</nmwg:parameter>
      <nmwg:parameter name="valueUnits">frames</nmwg:parameter>         
    </netfram:parameters>   
    
  </nmwg:metadata>

  <nmwg:metadata id="iumeta2" metadataIdRef="iumeta1">
<!--
    The metadataKey is nothing more than a file that is
    generated by tools like cricket that describes a 
    interface on a machine.  This file can be used in the
    future for queries and saves the time of needing to
    search on specific parameters.  
-->  
     
    <netfram:subject id="iusub2">
      <nmwgt:interface>
        <nmwgt:direction>in</nmwgt:direction>
      </nmwgt:interface>
    </netfram:subject>
  </nmwg:metadata>

  <nmwg:metadata id="iumeta3" metadataIdRef="iumeta1">
     
    <netfram:subject id="iusub3">
      <nmwgt:interface>      
        <nmwgt:direction>out</nmwgt:direction>
      </nmwgt:interface>
    </netfram:subject>
  </nmwg:metadata>


  <!-- Metadata(s) using new topology schema -->

  <nmwg:metadata id="iumeta4">
    <netfram:subject id="iusub4">

    <!-- we could use any of the specific interfaces from 
         topo as well ... (L2, L3) -->
         
      <nmwgtopo3:interface id="d1">     
        <nmwgtopo3:name type="string">dreadnought</nmwgtopo3:name>
        <nmwgtopo3:type>pc</nmwgtopo3:type>
        <nmwgtopo3:hostName>dreadnought.cis.udel.edu</nmwgtopo3:hostName>
        <nmwgtopo3:ifName>eth0</nmwgtopo3:ifName>
        <nmwgtopo3:ifDescription>gigE</nmwgtopo3:ifDescription>
        <nmwgtopo3:ifIndex>0</nmwgtopo3:ifIndex>
        <nmwgtopo3:capacity>1000000000</nmwgtopo3:capacity>
      </nmwgtopo3:interface>
    </netfram:subject>
    
    <netfram:parameters id="param4">
      <nmwg:parameter name="interval">1</nmwg:parameter>
      <nmwg:parameter name="valueUnits">frames</nmwg:parameter>         
    </netfram:parameters>   
    
  </nmwg:metadata>

     




  <!-- The following methods deal with a factored
       commonTime strategy.
  -->    

  <nmwg:data id="data1" metadataIdRef="iumeta1">   
    <nmwg:commonTime type="unix" value="1107492095">
      <netfram:datum type="ifInErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifOutDiscards" value="234567890" valueUnits="frames"/>
    </nmwg:commonTime>
  </nmwg:data>

  <nmwg:data id="data2" metadataIdRef="iumeta1">
    <nmwg:commonTime type="unix">
      <nmtm:value>1107492095</nmtm:value>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
    </nmwg:commonTime>
  </nmwg:data>
  
  <nmwg:data id="data3" metadataIdRef="iumeta1">   
    <nmwg:commonTime type="interval" duration="30">
      <nmtm:start type="unix" value="1107492095"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifInErrors" value="234567890" valueUnits="frames"/>
    </nmwg:commonTime>
  </nmwg:data>
   
  <nmwg:data id="data4" metadataIdRef="iumeta1">
    <nmwg:commonTime type="interval" duration="30">
      <nmtm:start type="unix">
        <nmtm:value>1107492095</nmtm:value>
      </nmtm:start>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
    </nmwg:commonTime>
  </nmwg:data>
    
  <nmwg:data id="data5" metadataIdRef="iumeta1">   
    <nmwg:commonTime type="range">
      <nmtm:start type="unix" value="1107492095"/>
      <nmtm:end type="unix" value="1107492395"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames"/>
    </nmwg:commonTime>
  </nmwg:data>
   
  <nmwg:data id="data6" metadataIdRef="iumeta1">   
    <nmwg:commonTime type="range">
      <nmtm:start type="unix">
        <nmtm:value>1107492095</nmtm:value>
      </nmtm:start>
      <nmtm:end type="unix">
        <nmtm:value>1107492095</nmtm:value>
      </nmtm:end>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
      <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames"/>
    </nmwg:commonTime>
  </nmwg:data>       


  <!-- Inline everything for single items (not really good for
       large groups) if you want to be compact.
  -->
  <nmwg:data id="data7" metadataIdRef="iumeta1">
    <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames" timeType="unix" timeValue="1021119880"/>
  </nmwg:data>
  
  
  <!-- If a commonTime is not applicable, and inlining time doesnt describe
       the time well enough, make a time element be a child of each datum.  It
       has a couple ways of being described
  -->
  <nmwg:data id="data8" metadataIdRef="iumeta1">    
    <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames">
      <nmtm:time type="unix" value="1021119880" />
    </netfram:datum>
  </nmwg:data>  

  <nmwg:data id="data9" metadataIdRef="iumeta1">   
    <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames">
      <nmtm:time type="unix">
        <nmtm:value>1021119880"</nmtm:value>
      </nmtm:time>
    </netfram:datum>
  </nmwg:data> 

  <nmwg:data id="data10" metadataIdRef="iumeta1">
    <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames">
      <nmtm:time type="interval" duration="30">
        <nmtm:start type="unix" value="1107492095"/>
      </nmtm:time>
    </netfram:datum>
  </nmwg:data> 

  <nmwg:data id="data11" metadataIdRef="iumeta1">    
    <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames">
      <nmtm:time type="interval" duration="30">
        <nmtm:start type="unix">
          <nmtm:value>1107492095</nmtm:value>
        </nmtm:start>  
      </nmtm:time>
    </netfram:datum>
  </nmwg:data> 

  <nmwg:data id="data12" metadataIdRef="iumeta1">   
    <netfram:datum type="ifOutErrors" value="234567890" valueUnits="frames">
      <nmtm:time type="range">
        <nmtm:start type="unix" value="1107492095"/>
        <nmtm:end type="unix" value="1107492395"/>
      </nmtm:time>
    </netfram:datum>
  </nmwg:data> 

  <nmwg:data id="data13" metadataIdRef="iumeta1">    
    <netfram:datum type="ifInDiscards" value="234567890" valueUnits="frames">
      <nmtm:time type="range">
        <nmtm:start type="unix">
          <nmtm:value>1107492095</nmtm:value>
        </nmtm:start>
        <nmtm:end type="unix">
          <nmtm:value>1107492395</nmtm:value>
        </nmtm:end>
      </nmtm:time>
    </netfram:datum>
  </nmwg:data>   

  <!-- result datum elements -->
  <nmwg:data id="data14" metadataIdRef="iumeta1">  
    <nmwgr:datum type="error.iu.mp">eth0: error fetching interface information: Device not found</nmwgr:datum>
  </nmwg:data> 
  
</nmwg:message>  
# ##############################################################
# 
# File:         framemetric.rnc - Specialized schema for the 
#                                 measure of interface framemetric
# Version:      $Id$
# Purpose:      Describes specific elements to be used in the
#               representation and handling of interface 
#               framemetric
# Reference:    http://books.xmlschemata.org/relaxng/page2.html
#                         
# ##############################################################
        

# ##############################################################
# Namespace definitions
# ##############################################################
namespace nmwg = "http://ggf.org/ns/nmwg/base/2.0/";
namespace framemetric = 
"http://ggf.org/ns/nmwg/characteristic/framemetric/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 |= framemetricMetadata
        Data |= framemetricData        
} 


# ##############################################################
# 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/";>
# 
#   <!-- TBD OPTIONAL SUBJECT -->
# 
#   <!-- TBD OPTIONAL PARAMETERS -->
#
#   <!-- TBD OPTIONAL EVENTTYPE -->
# 
#   <!-- TBD OPTIONAL KEY -->
#  
#   <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE --> 
#
# </nmwg:metadata>
# 
# ##############################################################
        
framemetricMetadata = 
        element nmwg:metadata {
                Identifier &
                MetadataIdentifierRef? &
                framemetricMetadataContent
        }
          
framemetricMetadataBlock = 
        framemetricSubject? &
        (
                framemetricParameters |
                Parameters
        )?
        
framemetricMetadataContent = 
        (
                framemetricMetadataBlock |
                FilterMetadataBlock                
        ) &        
        EventType? &
        Key?        


# ##############################################################
# Redefined framemetric subject allows only an interface, and
# the two id attributes.    
#
# Example: 
# 
# <framemetric:subject id="REQUIRED_ID" 
#               metadataIdRef="OPTIONAL_REFERENCE_ID"
#               xmlns:nmwg="http://ggf.org/ns/nmwg/tools/framemetric/2.0/";>
# 
#   <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>
#  
# </framemetric:subject>
#
# ##############################################################

framemetricSubject =
        element framemetric:subject {
                Identifier &
                MetadataIdentifierRef? &                
                (
                        Interface |
                        BaseInterface |
                        L2Interface |
                        L3Interface
                )
        }


# ##############################################################
# This is simply the regular method of doing parameters with an
# enumeration to limit what 'names' are accepted and an outer
# framemetric: namespace for the parameters.
#
# Example: 
# 
# <framemetric:parameters id="REQUIRED_ID" 
#                   
xmlns:nmwg="http://ggf.org/ns/nmwg/tools/framemetric/2.0/";>
# 
#   <nmwg:parameter name="REQUIRED_ENUM_NAME" value="OPTIONAL_VALUE"
#                   xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
# 
#     <!-- ANY TEXT, (IF YOU DID NOT USE THE VALUE ATTRIBUTE) -->
# 
#   </nmwg:parameter>
#  
#   <!-- MORE PARAMETERS -->
#   
# </framemetric:parameters>
# 
# ##############################################################

framemetricParameters =
        element framemetric:parameters {
                Identifier &        
                framemetricParameter+
        }
        
framemetricParameter = 
        element nmwg:parameter { 
                attribute name { "interval" | "valueUnits" } &
                (
                        attribute value { text } |
                        text
                )
        }


# ##############################################################
# 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/";>
# 
#   <!-- OPTIONAL (MULTIPLE) METADATA -->
# 
#           <!-- OR -->
#
#   <!-- TBD OPTIONAL (MULTIPLE) COMMON TIME ELEMENTS AND 
#        OPTIONAL (MULTIPLE) DATUM ELEMENTS-->
# 
#           <!-- OR -->
#  
#   <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
# 
#           <!-- OR -->
#  
#   <!-- OPTIONAL (MULTIPLE) KEY ELEMENTS -->
# 
#           <!-- OR -->
# 
#   <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
#   
# </nmwg:data>
# 
# ##############################################################
   
framemetricData =
        element nmwg:data {
                Identifier &
                MetadataIdentifierRef? &
                (
                        (
                                Metadata* |
                                framemetricMetadata*
                        ) |
                        (
                                framemetricCommonTime+ & 
                                (
                                        framemetricDatum* |
                                        ResultDatum*
                                )
                        ) |
                        (
                                framemetricDatum* |
                                ResultDatum*
                        ) |
                        Key*
                )
        }


# ##############################################################
# 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/";>
# 
#   <!-- TBD OPTIONAL START TIME ELEMENT (USE END TIME OR DURATION) -->
#  
#   <!-- TBD OPTIONAL END TIME ELEMENT (ONLY WITH START TIME) -->
#  
#   <!-- TBD OPTIONAL TIME VALUE ELEMENT (USE IF NO VALUE ATTRIBUTE) -->
#  
#   <!-- TBD OPTIONAL (MULTIPLE) DATUM ELEMENTS -->
# 
#   <!-- ANY OPTIONAL (MULTIPLE) ELEMENT IN ANY NAMESPACE -->
# </nmwg:commonTime>
# 
# ##############################################################

framemetricCommonTime = 
        element nmwg:commonTime {
                Type &
                (
                        TimeStamp |
                        (
                                StartTime & 
                                (
                                        EndTime | 
                                        Duration 
                                )
                        )
                ) &
                (
                        framemetricDatum* |
                        ResultDatum*
                )
        } 


# ##############################################################
# These are the basic elements we would expect to see in the 
# specific iperf datum.
#
# Example: 
# 
# <framemetric:datum value="REQUIRED_VALUE"
#                    valueUnits="OPTIONAL_VALUE_UNITS"
#                    timeType="OPTIONAL_TIME_TYPE"
#                    timeValue="OPTIONAL_TIME_VALUE"
#                    
xmlns:nmwg="http://ggf.org/ns/nmwg/tools/framemetric/2.0/";>
# 
#   <!-- TIME ELEMENT (IF ATTRIBUTES NOT USED) -->
#  
# </framemetric:datum>
# 
# ##############################################################

framemetricDatum =
        element framemetric:datum {
                attribute type { xsd:string } &
                attribute value { xsd:float } &
                attribute valueUnits { xsd:string }? &        
                (
                        (
                                attribute timeType { xsd:string } & 
                                attribute timeValue { xsd:string }
                        ) |
                        Time
                )?                         
        }