[Nml-wg] XML syntax for NML relations

[Jason Zurawski]

Hi Freek;

Answers inline:

On 8/23/11 6:21 PM, thus spake Freek Dijkstra:
> Hi Jason,
>
> We indeed seem to miscommunicate.
>
>>>>> 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.
>
> 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").

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.  Writing text in a specification is one thing that can be 'easily' 
done; but OGF standards are meant to apply to existing and future 
problems.  Your modifications are not impossible to do, "a mere matter 
of code" perhaps, but I really question why?  What is it gaining this group?

Bringing the conversation back to the reality of implementation, it is 
strongly desirable to re-use existing tool when possible.  This 
simplifies development and fosters adoption.  All of my answers thus far 
are using the lens of experience with the tools, and experience with a 
'living' data specification format.  It is a non-trivial task, and using 
what is out there makes things much easier.

To date there is nothing that needs to be specified in NML that cannot 
be encoded in XML (or RDF) given the existing paradigms and tools.  The 
changes you are proposing to me do not sound implementable because its 
simply not the way that XML and XML schema work.  If you want to try to 
do these ideas, I applaud your initiative, but I question what it is 
really gaining given that the current method has solved the 
extensibility and interoperability questions.

> I did not propose any text yet, I also did not think you should do that
> (though I would certainly value your input), nor that it should be done now.
>
>
> (As a side note: the reason for bringing up the validation requirement
> is that I hope to re-use existing parsers and validators, and thus avoid
> the need to craft a new parser.)
>
>
> On the other topics:
>
>> 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.
>
> I don't know how to explain it in email without repeating what already
> has been said before. The only thing I can think of is actually defining
> a full schema and writing an implementation that parses it.
>
> Perhaps implementing is a good idea given the amount of talking that we
> did so far :). In any case, I'm now on holiday till September 12. I will
> leave coming weekend for two weeks, and will not be able to write that
> before that time, given that I'm better versed in RDF than in XSD. (and
> given that I'm not even a true RDF expert that means I'm an XSD-Noob ;) .)

I look forward to reading your approach;

-jason