[Nml-wg] XML syntax for NML relations

[Freek Dijkstra]

Jason Zurawski wrote:

>>      <nml:link id="urn:ogf:network:example.net:link_A-to-C">
>>        <nmlserialcompound:relation>
>>           ...
>>        </nmlserialcompound:relation>
>>      </nml:link>
> 
> I would prefer there to be just 'nml:relation' because it is still not 
> clear to me what you intend to put in the 'nmlserialcompound' 
> relationship that is special enough to be in a different namespace.

I meant it as a generic example of an extension to the base relations.
It could be just as well:
  <nmlversion2:some_future_relation_we_havent_thought_of_yet>

or in your preferred syntax:
  <nml:relation type="some_future_relation_we_havent_thought_of_yet">

I meant nothing special by choosing this namespace in the example.

> In any event, what I think doesn't matter in this case, because your 
> sub-namespace (nmlserialcompound) would derive from the base namespace 
> (nml).  Which is the entire point of doing things in this manner.  Even 
> though its a special namespace, it can be reduced to the base which 
> should make services happy.

What do you mean with "special" namespace?
I'm currently not making any assumptions about the namespace.
(I only make the assumption that there is a schema that defines the
element nmlserialcompound:relation as a subclass of nml:relation)

>> How should the parser know that nmlserialcompound:relation inherits from
>> the base nml:relation? I can think of two things:
>>
>> - Because the parser has knowledge of the schema definition
> 
> Yes, its written in the schema implicitly.  If the parser for some 
> service was loaded with the 'nmlserialcompound' version of the schema, 
> that schema has to have in it somewhere that 
> 'nmlserialcompound:relation' is really just an 'nml:relation' that has 
> been extended.  This service is intelligent enough to parse both 'nml' 
> and 'nmlserialcompound' versions.

What I'm talking about is a service which does understand the generic
nml:relation concept, and some nml:relation subclasses, but not all
nml:relation subclasses.

I'm thinking about some some future extension. Let's say we create a NML
version 2 in 5 years time. How should a parser which knows about NML 1
handle a NML version 2 message? Fail completely, or is there a way to
make NML extensible from the start. E.g. by allowing someone to create a
new nml:relation subclass, without completely rewriting the NML base.

Thus: would it be possible to create a new schema that extends NML base,
and let old parsers (who are not aware of this new schema) know that the
message contains some additional relations based on this new extension?
It is my hope that a parser would be able to read the NML it does known,
and ignore the new schema additions.

> If you don't know the schema, you fail.  This is how it has to be.

You mean in the above scenario the parser should fail completely? Or
only ignore the unknown extensions?


>> - Because the parser assumes that all elements named "relation" are
>> subclasses of nml:relation.
> 
> I dont think you can make this assumption.

I'm pleased to hear that -- it was not clear to me from Roman's email if
he made that assumption or not, so I was polling for that.



>    <nmlserialcompound:relation  freeks_special_attribute="true" />
> 
> If this was passed to a service that doesn't understand 
> 'nmlserialcompound', the service could simply reject the entire element. 

That sound good to me.

It should reject the element, not the entire message. I think we agree
on that (good!).

>   It also could accept the foreign namespace, and attempt to parse the 
> element with the only version of relation it happens to know about 
> (nml).  This would mean that the foreign attribute would most likely be 
> ignored, but it still allows the message to be parsed.

I think we're on the right track here.

I like the above idea, that a service may attempt to parse the element
using some basic knowledge about the base. However, I don't like the
idea of a parser that comes across any unknown element and simply tries
to parse it using a base element, _without knowing if this unknown
element is actually a subclass of this base element_. So I want to
include some clue in the XML telling the parser just that ("hey, here is
a nmlserialcompound:relation, and if you don't know what that is, simply
treat it as a generic nml:relation")

The original syntax:
  <nml:relation type="serialcompound">

did this perfectly.

However, as I tried to explain, this particular syntax has a drawback if
you want to do meaningful syntax validation.

Hence my proposal.

>> For this reason, including the extra nesting with <nml:relations>  seems
>> to me a relative simple solution to solve these problems.
> 
> After your entire mail, I am not exactly sure how you reached this 
> conclusion.

Sorry, I left out a crucial bit in the email (no point in having this
clear in my head if I don't make it clear here):

All child elements of nml:relations MUST be a subclass of nml:relation.

> Lets say I had this:
> 
> <nml:relations>
>    <jason:relation>
>      <!-- other things ... -->
>    </jason:relation>
> </nml:relations>
> 
> I am still in the situation as you described above, and now I have an 
> extra element that really doesn't help me solve any problem.

So <jason:relation> must be a nml:relation subclass because of the above
requirement.

> If you are still unclear on the concept of the namespaces I am happy to 
> try to explain them more, but the exact things you are trying to solve 
> with the addition of more elements can be done through namespaces and 
> inheritance, NMC has done this for a while and it has worked well in 
> practice in perfSONAR.

I understand it, and I agree for most part that it works well, with the
exception of the syntax validation requirement.

I was trying to come up with a solution that has all the benefits that
the NMC gives, but also has this benefit. My first attempt at that
(<nmlserialcompound:relation>) failed, well, miserably (sorry, I'm not
that smart). I think (hope?) my second attempt
(<nml:relations><nmlserialcompound:relation>) does a better job at that.


Let me also try to clarify a point you made in your follow up email:

> It is a mistake to assume that a parser by itself is capable of rich 
> semantic interpretation.

I agree, that is not possible.
However, I do hope that a parser is -by only knowing a base schema and a
few (but not necessarily all!) schema extensions- able to validate the
SYNTAX as good as it can.

That is currently not the case in the current perfSONAR implementations,
and I regret seeing that.

I hope that by at least allowing easy and meaningful SYNTAX validation,
the parser code can concentrate on what is important: the SEMANTICS.
Thus the application specific stuff. I think that is where the real fun
is, and I hope to use some library for the boring SYNTAX checking stuff.

I DO think that SYNTAX checking is important (albeit boring); if we do
it well, we can can specify how parsers should treat syntactically
invalid messages, and avoid a slurry of implementation incompatibility
problems later.

Regards,
Freek