perfsonar development work

[Jason Zurawski <>]

Roman;


> > > I'd like to ask about datum element. For the utilization it looks 
> > > like this (taken from example response):
> > >
> > >    <nmwg:data id="d1" metadataIdRef="meta1">
> > >        <nmwg:datum timeType="unix" timeValue="1121558400"
> > >            value="0.19281761856741222" valueUnits="Bps"/>
> > >        <nmwg:datum timeType="unix" timeValue="1121644800"
> > >            value="0.1621709219533064" valueUnits="Bps"/>
> > >        <nmwg:datum timeType="unix" timeValue="1121731200"
> > >            value="0.34163606985698564" valueUnits="Bps"/>
> > >        <nmwg:datum timeType="unix" timeValue="1121817600"
> > >            value="0.3812493124312431" valueUnits="Bps"/>
> > >    </nmwg:data>
> > >
> > >
> > > In 
> > > http://anonsvn.internet2.edu/svn/nmwg/branches/snmp/example_instances/errors/SDResponse1.xml 
> > > I see that 'error' namespace is used for datum. Do we really need 
> > > this new namespace here. Why not use just 'nmwg'. Datum of 'nmwg' 
> > > namespace is generic for values of both metrics (utilization and 
> > > errors) stored in rrd files.
> > >
> > > I propose to use only 'nmwg' namespace for datum element.
> > >
> > > (the same with discards)
> > Much like parameters can be in the general (nmwg) namespace and a 
> > specific (utilization/errors/discards, etc.) datum behaves the same 
> > way.  The added benefit here is that in instances where we *may* want 
> > to check results against a strict schema we are able to do so.
> The format of data is the same for utilization/errors/discards so we 
> can reuse datum element (schema) of nmwg namespace. eventType value 
> from chained metadata says what metric is fetched.



Yes, I agree its the same namespace now but future modifications may 
require it to not be the same.  There is no hard requirement to use the 
utilization/errors/discards/snmp namespaces and using nmwg is perfectly 
fine.  For our services in particular we plan on tying the datum 
namespace directly to the eventType, as such the visualization and 
client applications should be aware of this and become nimble enough to 
handle the choice. 


-jason