Hi Freek, All;
Regarding the issue of 'why nmc' instead of something like WSDL, the idea was sprung from the original use case of encoding measurements. The rationale at the time was if we were using an encoding scheme for the measurements, wrapping a similarly constructed control structure around each for communication was not a far stretch and may even make the job of parsing and interpreting the information easier.
As I said, I think the ideas are good. You mention "at the time". Would you do it differently if you were to redesign the schema? Perhaps my actual question is: does this doc describe the current practice as it has been done so far or is it an attempt to combine all good ideas into the best standard possible? If it is describing the current practice, would it be useful to improve it, or would that require too much rewriting for application developers?
According to the NMC charter:
The purpose of the Network Measurement and Control Working Group is to standardize the XML-based protocols that are currently in use in the perfSONAR project to control network measurement infrastructure and to share the results of the measurements and metrics that are generated.
As such we should be describing the current generation of communication protocols for perfSONAR varients. I would anticipate that minor changes may be required, for example Roman's suggestion that we avoid talking about a specific portion of the existing protocol, 'supportedEventType', comes from a short lived implementation hack (short lived = going on 2 years :)) that we do not wish to place into a protocol discussion. I don't view this group as a way to combine all the 'good' ideas because most ideas have been implemented and are in practice for many years now. If switching to WSDL was viable or popular, it would have happened already.
[...] automated syntax check for messages. Has this been done so far?
In practice services don't implement a strict schema check since it can be expensive, but the tools exist for both major implementations to do this.
Message validity checking was one thing advocated by someone from UNINETT (The Norwegian NREN). I think it was either Arne Øslebø or Jon Hellan. Perhaps Roman remembers who it was. We could ask them exactly why they thought that to be useful.
I believe validity checking is useful in cases where active development is taking place (e.g. reverse engineering what is and is not possible) as well as if you are not using an API to talk to services directly. Otherwise it seems like a waste of cycles (to me) to constantly check messages that are probably very similar. Regardless, this is more of a implementation issue and doesn't seem directly related to protocol development.
Last, the wording could be better in some places, especially when it comes to the RFC 2119 words (MUST, SHOULD, MAY). [...]
It would be very helpful if you could go through and correct these mistakes as you see them - particularly since you have experience in writing documents of this nature. May I mark you down as willing to do this task?
You just did ;-)
I have marked you down on the TODO list. -jason