[Nml-wg] XML syntax for NML relations (was: Multiple namespaces)

[Freek Dijkstra]

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