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