perfsonar-dev - Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema
Subject: perfsonar development work
List archive
- From: Roman Lapacz <>
- To:
- Cc:
- Subject: Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema
- Date: Mon, 06 Aug 2007 14:08:27 +0200
Jason Zurawski wrote:
Roman & All;
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.
Roman
A service can of course choose to return the formated data anyway it wants to (this could even be turned off/on via some sort of parameter in the message). It is important for client/visualization tools especially to be aware that both formats are acceptable.
-jason
- Conclusions and Open Issues for Errors/Drops Schema, David Schmitz, 08/03/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Jason Zurawski, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
- Re: [pS-dev] Conclusions and Open Issues for Errors/Drops Schema, Roman Lapacz, 08/06/2007
Archive powered by MHonArc 2.6.16.