[Nml-wg] XML syntax for NML relations

[Jason Zurawski]

Hi Freek;

Answers inline:

On 8/23/11 11:15 AM, thus spake 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 fail to understand why this is better than using a alternate namespace 
on existing element from base. It is unclear to me how you propose to 
facilitate this 'subclass' idea using the avalable tools and constructs 
of XML.  You have introduced two new elements: 'relations' and 
'somethingrelation', and both have no relationship to the base class 
that I am able to tell.  If you are proposing that both of these *be* 
the base class, than my argument is that you will need to enumerate all 
possible children of 'relations' beforehand, otherwise there is no 
longer any expected extensibility.

In my opinion, all your modifications have does is add complexity (e.g. 
now there is a spurious new 'level' by requiring that people use 
'relations') and the notion of 'subclassing' that still cannot be 
enforced via syntactic means.  It is not clear to me how you intend to 
enforce 'somethingrelation' having a relationship to 'relation' with 
just XML, these are completely different elements and XML isn't fully 
featured enough to allow what you want to do.  This last point destroys 
the aspect of extension, and would force new designs to modify the NML 
base each time a new relationship is constructed.

>> 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,

See my argument above, based on your proposal is not clear to be how you 
intend to foster extension with the d).  You are introducing elements 
that have no relationship to each other.  If I am go to on what you have 
provided, I am left to think that you are destroying the ability to 
extend by creating single use elements that cannot be extended.   You 
get strict validation, but all use cases for the relationships must be 
known by the base.

Perhaps your example makes perfect sense to you in, but I am not seeing 
any clear benefit.

> 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) added one additional level of nesting to the XML messages. 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.

Please provide an example of how you intend to this in either RNC or XML 
Schema.  Please be complete in your example so we can critique it, if 
you need help in using MSV/Jing/Trang, see this README:

http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/schema/README.txt

My statement on this matter is born out of experience, and I am happy to 
admit my faults and errors if you have some proof of operational 
soundness in doing this approach.

>> 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).

I am not following your argument here at all.  I believe there is still 
a very serious disconnect between us and perhaps this is where it comes 
from.

Based on your statements above, you want to allow the concept of 
subclassing for the 'relation' element, and you propose to do this by 
allowing 'somethingrelation' and 'somethingrelation2', etc. have this 
property.  I am claiming it does not work this way, and that the 
features you wish to achieve (subclassing) must be done using the 
alternative namesapces I have been describing for more than a month.

To summarize:

Base = nml:relation
Something sub class = something:relation
Something 2 sub class = something2:relation

The elements are the same, the namespaces are different.  If you want to 
call them 'subclasses', so be it, but recall that we are not dealing 
with a programming language here.  We are dealing with a markup language 
that probably was *never* intended to do all of the fully featured 
things that NMC or NML wish to do.

I am well aware of your dislike of the 'type' element, you clearly 
stated this in SLC, and most of these emails.  Whatever your reasons 
are, I am only going to note that your attempt to defeat it using the 
current approach of adding new elements is not working to convince me. 
I see clear extensibility problems, and I will continue to tell you 
about them each time you bring them up.

>>> 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.

You are entitled to do whatever you believe to be the correct answer. 
This group does not need to follow the NMC method if you feel it is 
fatally flawed, and I will still encourage you to start fully 
enumerating your proposed new approach beyond simple snippets of XML.

> 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 am going to stop you there and note this is more than 7 years old, 
represents a demo service that is no longer in development, and is not 
maintained by anyone.  It is not the best thing to use for a comparison.

> 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?

I do not agree, because crafting a new parser seems to be unnecessary 
busy work without any clear advantage for the group.  This is an effort 
to create a standard, and I would think that incorporating existing 
technology when possible is a positive step.  Given that, and peaking 
for my time requirements only - I cannot contribute any help to do this.

If you still feel this is the direction you wish to take, I look forward 
to reviewing what you are able to produce as an alternative approach to 
what is on the table right now.

Thanks;

-jason