[Nml-wg] Dealing with unknown relations

[Freek Dijkstra]

On 17-08-2012 16:37, Jeroen van der Ham wrote:
> Hi,
> 
> On 17 Aug 2012, at 14:57, Freek Dijkstra <freek.dijkstra at sara.nl> wrote:
>> I like NML to be extensible. For example, if some NML publisher likes to
>> add information that benefits monitoring or provisioning, that should be
>> possible.
>>
>> A NML receiver should silently ignore this added information. However,
>> we also don't want a receiver to just accept anything. If there is some
>> obvious error in the NML, the receiver should still just reply with an
>> error message.
> 
> I am not entirely sure that we can reasonably make this distinction.

Regardless if we can or not (we can and in fact already do, by the way):
is it useful?

The alternative is that the receiver should accept anything, including
obvious errors in the NML.

That doesn't seem useful to me. Are you suggesting that accepting
obvious errornous NML is useful, or merely stating that while it's
useful you don't see how to make it happen?

> And even if we can, without bloating the current schema into probably
> twice its current size.

We already did that. You even wrote down the text yourself. So no, it
does not bloat it. Again, see this example:

>> In fact, the current document makes this distinction. To quote the text
>> on "hasService":
>>
>>> hasService relates a Network Object to a Service. This schema only
>>> defines the meaning of:
>>> • Port to AdaptationService, relating one server-layer Port to an
>>>  adaptation function
>>> • Port to DeadaptationService, relating one server-layer Port to a
>>>  deadaptation function
>>> • Node or Topology to SwitchingService, describing a switching
>>>  capability of that Node or Topology.

[..]

>> So in this case "Port P --hasService--> LabelService L" would be
>> syntactical VALID NML but with UNDEFINED meaning. "Node N
>> --hasService--> Node Y" would simply be syntactically INVALID NML.
> 
> I am not sure how you make that distinction based on the description
> given above. For both Port and Node there is a possible "hasService"
> relation defined, and neither "LabelService" nor "Node" are defined as
> possible ranges of the hasService relation.
> 
> Just the fact that "LabelService" is a new kind of object should not make it different.

If we write it as <nml:Service type="http://.../LabelService"> than it
is obvious that this is a NML Service. Also, it is clear that a NML Node
is not a subclass of Service, so I think they're different.

Freek