[Nml-wg] XML syntax for NML relations

[Jason Zurawski]

Freek;

Answers inline:

On 8/23/11 7:34 PM, thus spake Freek Dijkstra:
> Jason Zurawski wrote:
>> Changing how a parser behaves is akin to writing a new parser.  You are
>> altering something that was designed to handle the XML or XML schematic
>> spec.
>
> I don't understand. Change what? Altering what?

Yes, it is very hard to understand when you completely cut all of the 
context from the mails.

Here it is again:

> I do not understand why you bring up the desire or non-desire to craft a
> new parser. I was only suggesting that it would be useful to define in
> the NML specification what a parser should do in case it encounters an
> element it does not understand. (e.g. write some text along the lines of
> either "a client SHOULD reject the message" or "a client SHOULD ignore
> the unknown element").

Your statement claims a desire to specify, in the NML spec document 
language, rules that dictates how a parser should behave when it 
encounters elements it is not aware of.  Rules must be translated into 
code at some point, and unless you mean something completely different 
than this statement, you are implying that NML will be passing rules to 
a parser how to behave.  In my experience, changing this behavior is 
non-trivial, and thus alters how it functions vs other forms of XML and 
XML schemata.

My argument from the prior email is that this seems like a silly task to 
be concerned with given the entire purpose of this group is to specify a 
network markup language, not critique or modify the current state of web 
service tools.  Our time should be spent on these concepts, not 
bickering about technology.

> I wrote:
>> The bottom line is that we should DEFINE in the NML specification how
>> parsers should behave in [..] case [an unknown XML is encountered].
>
> I don't recall that an existing NML parsers exists (I am aware of Pynt,
> which is a NDL parser, and perfSONAR-PS and perfSONAR-MDM, which are NM
> parsers).

The current working version of "NML"*, for instance the Circuit 
monitoring work produced by Aaron and Roman, is based on XML - it is 
parsed by XML parsers.  The prior generation of both perfSONAR and the 
IDCP use concepts that NML still pushes today (e.g. nodes, links, ports) 
is also based on XML.  If NML is not recognizing these work items as 
being related or a useful product to start from, than perhaps we need to 
take several large steps back as a group.

* = NML because the work was done by regular NML members, using NML 
concepts.

> But let's for a moment assume such a parser exists, all I am saying is
> that it would be useful useful to DOCUMENT its behaviour.
>
> I'm not asking for whatever behaviour you think is desirable to change,
> altered or jump through loops. I'm asking for whatever is out there (or
> is going to be written) to be documented.
>
> Really.
>
> Please don't mix in other discussions. It is complicating enough getting
> the two of us on the same par. :)

So far you have not convinced me that your alternative approaches to 
constructing subclasses are any better (in fact I have tried to show 
they are worse in key areas) than the methods utilized in NMC/perfSONAR. 
  It is unlikely you will be moving me with your ideas, just as sure it 
is very unlikely that I will be moving you with mine.  Things are 
entrenched, and that is fine.  You seem to very keen to explore your 
alternate proposals for how the schema and instances should be 
constructed, and I do applaud you for that.  Research is fun, and for 
people who have the time, very rewarding.

I believe its best that we agree to disagree, and if you are able to 
construct your alternate methods the group as a whole can evaluate them. 
  Until that day happens, there are services in existence using the NML 
concepts, in XML form, rather successfully including a circuit 
monitoring tool going into production on backbone/regional networks as 
well as several end sites.  I believe it is important to tout these 
successes, and build upon this work as much as possible.

If you feel that NML needs to take an alternative direction in this 
schematic design to make the work stronger overall, the group will 
listen to your proposal when it is prepared.

Thanks;

-jason