[Nml-wg] XML syntax for NML relations

[Jason Zurawski]

Hi Freek/All;

On 8/16/11 8:32 AM, thus spake Freek Dijkstra:
> Comments follow original text:
>
> Roman Łapacz wrote:
>
>>> So far, we have seen these two proposals:
>>>
>>>     <nml:link id="urn:ogf:network:example.net:link_A-to-C">
>>>       <nml:relation type="serialcompound">
>>>          ...
>>>       </nmlserialcompound:relation>
>>>     </nml:link>
>>>
>>> and:
>>>
>>>     <nml:link id="urn:ogf:network:example.net:link_A-to-C">
>>>       <nmlserialcompound:relation>
>>>          ...
>>>       </nmlserialcompound:relation>
>>>     </nml:link>
>>>
>>> The advantage of the first syntax is that it is very easily extendable,
>>> and it is still obvious for a parser to understand that it is some kind
>>> of nml:relation, even if the particular type of relation is not known by
>>> the parser.
>>>
>>> The advantage of the second syntax is that it is easy to create a
>>> meaningful validator for each specific nml:relation.
>>>
>>>
>>> I dislike both syntaxes, and was hoping for a syntax that would provide
>>> both benefits.
>>>
>>> If I'm correct, the following syntax will do just that:
>>>
>>>     <nml:link id="urn:ogf:network:example.net:link_A-to-C">
>>>       <nml:relations>
>>>         <nmlserialcompound:relation>
>>>            ...
>>>         </nmlserialcompound:relation>
>>>       </nml:relations>
>>>     </nml:link>
>>>
>>> This adds a parent element to the relation elements, signifying that
>>> <nmlserialcompound:relation>   is indeed a nml:relation. So even a parser
>>> that has no knowledge about this particular nml:relation still knows
>>> it's base syntax, while a parser that understands the details can still
>>> use an meaningful syntax validator (such as XSD) to make sure the syntax
>>> is correct.
>>
>> The solution with namespaces gives you that (nmlserialcompound:relation
>> inherits from the base nml:relation). nml:relations only complicates the
>> xml structure without giving too much.
>
> You mean you prefer the following?:
>
>      <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.  Do 
you have examples of what you intend to do with this relationship?

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.

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

The converse is that a service that has no knowledge of the 
'nmlserialcompound' relationship may not be able to read the elements. 
It would only be able to interpret the relations as 'nml' - if it is 
able to interpret them at all.  Strict validation may force the 
'nmlserialcompound' namespaced elements to be ignored or rejected 
(depends on the semantic rules).

> - Because the parser assumes that all elements named "relation" are
> subclasses of nml:relation.

I dont think you can make this assumption.  It is true that some 
non-strict checking services may take this path, but semantic rules can 
be enforced if so desired.

> The problem with the first is that it requires all parsers known all
> schemas beforehand. I see a risk with backward compatibility after
> future extensions if that is required.

This is a little extreme - note that the 'standard' use case would be 
that all services would have knowledge of the base.  This is the 
'english' (so to speak) of web services.  Since all elements derive from 
this base dialect, it is assumed that services will communicate and be 
assured that their messages are semantically correct.

If you implement a service that absolutely requires a special namespace 
(e.g. 'nmlserialcompound' for some reason) this encoding will *only* 
make sense to other services that understand it.  E.g. the services are 
now speaking a different language.  Here is an example:

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

As I have said in previous exchanges - special dialects are useful if 
you intend to have specialized services and clients.  From the 
perfSONAR/NMC world we are constructing the 'base' protocol that is 
really useless by itself - no services speak 'base'.  We are also making 
a Measurement Archive protocol which is an extension of the base and 
uses concepts that only this type of service would care about.  No 
services will speak this explicitly.  Lastly there would be specific 
forms of data that a service would be expected to speak (e.g. throughput 
data, one way delay data, snmp data, etc.).  These are the dialects that 
the services would be comfortable speaking.  You can't simply send a 
request to utilization to a service that only speaks one way delay - 
even though the messages have the same structure, the semantics of what 
is being requested are slightly different.  The service can attempt to 
parse the message in a base dialect, but most likely will reject things 
outright.

> The problem with the second is that this fails if some schema (for
> whatever reason) includes a namespace where relation has a different
> meaning. Eg: family:relation or work:relation.

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

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

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.

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.

Thanks;

-jason