Hi Jason, I don't claim to be an NM expert like yourself, but have of course read the NM message specification and the examples in the PerfSONAR-PS code. Jason Zurawski wrote:
For example:
a) <relation type="something"> <link /> <link /> </relation>
vs.
b) <somethingrelation> <link /> <link /> </somethingrelation>
vs
c) <something:relation type="something"> <link /> <link /> </something:relation>
vs d) <relations> <somethingrelation> <link /> <link /> </somethingrelation> </relations> (where every direct child element of <relations> MUST be a subclass of the base class "relation").
I would argue that a) is our base, it is generic and minimal.
I'm well aware that this is in use in NMC, and served 2 out of the 3 requirements, which is pretty good for most purposes.
Schema is schema, you can construct whatever type of validation system you wish to implement. I would question how far you would want to take this exercise because there are tradeoffs that sacrifice other desirable qualities. My statement from prior conversation still stands - if you wish to do strict syntactic validation, to the point of trying to use the parser as a semantic analyzer as well, you give up a portion of #1; this is the tradeoff that must be considered.
All I was trying to suggest is that it occurs to me that d) would serve 3 out of the 3 requirements, and I was asking if someone on the list saw any serious problems with it. The only problems I have heard so far were that it (1) deviated from the solution in use for NMC, and (2) . Both arguments have their merits, but have not convinced me for choosing a) over d). However, you just pose a new argument:
The b) option is the creation of a new element, something that *does not* derive from the base, and therefore cannot be cast into something different.
I must disagree. In the case of b) and d) above, the schema definition file should define "somethingrelation" as a subclass of "relation". (and I presume that they are). In that case, "somethingrelation" is derived from the base.
The c) option is an extension namespace of the a) element.
In the above examples a), b) and c), I have no preference as to which namespace the elements belong. The issue on whether the type should be a value in an attribute (a), or in the name of the element (b and d) seems orthogonal to the choice of namespace (b versus c).
3. Parsers should be able to recognise an unknown relation type as a relation subclass (rather then simply an unknown element)
Every parser is different in this respect, and I am not going to be able to give you a concrete answer.
[... long and well written argument skipped ...]
Hope this all helps;
Thanks for your long answer, it was helpful. It occurs to me that an "strict syntactic checking" may entail two different concepts: a very strict schema (where any message with unknown elements is invalid and thus rejected by parsers) and a detailed scheme which does list all known details (but with provisions for unknown elemet (where parsers are able to parse the elements it is aware of, but ignore the elements it does not know). I'm much in favour of the second concept; you seem to argue about the first concept (which I personally (also?) do not like) in your email. To bring in the NM analogy, I very much like the RNC files in the perfSONAR-PS code, which is detailed and yet still flexible. I do not like the (unused?) WSDL files in the MDM code, which only define the message type, but not how it looks like. Compare the RNC files from your previous email to http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/perl/server/NMWG.wsdl I would even favour something which is even more detailed then the RNC files (and I agree that this is just a personal preference which we indeed have already debated enough just yet :) ).
If an unknown element comes in, many parsers will [...]
Your original sentence stated "reject the whole message". The bottom line is that we should DEFINE in the NML specification how parsers should behave in that case. I think we should add this item on the todo list for this WG and solicit input from any contributor on the list to propose such specification. Jason, would you agree this is a valid todo item for the group? Regards, Freek