On Jun 28, 2012, at 2:12 PM, Freek Dijkstra wrote:

At the call earlier today we shortly discussed how to deal with future
extensibility of NML.

Let me give two practical examples:

1) Topologies may change over time, and the "version" attributed is used
as a serial number to distinguish between updates in the Topology
description (akin to the serial number in DNS SOA records). Currently
this version attribute is only allowed for Topologies; allowing it for
each network object may complicate change management more than needed.
However, we can envision a situation where a future NML version would
allow this use.

2) the "hasTopology" relation is only allowed between two Topologies,
but perhaps in the future NMLv2 allow it from a Service to a Topology.

We hope that the following will work:

* The schema (UML schema, RDF schema and XML schema) will be "loose":
they will liberally allow all sorts of extensions. In the above
examples, the version attribute can be part of all Network Objects, and
hasTopology may relate any Network Object to a Topology.

* In the text, we will add further restrictions about the behaviour of
NML version 1 compliant agents. In the above examples, a NMLv1 generator
SHOULD NOT add version attributes to non-Topology network objects; a
NMLv1 parser SHOULD ignore version attributes for non-Topology network
objects; the meaning of the "hasTopology" relation between a Service and
a Topology is undefined, and SHOULD be ignored by NMLv1 parsers.

* Specific application may pose further restrictions on the NML
descriptions that are generated and parsed. For example, NSI may impose
restrictions how a STP is described in NML.

Is this a useful way forward that both allows extensibility, without
allowing too many variations (and thus interoperability) of NML?

I think this is a general case of "undefined attributes or relationships are undefined". If someone adds a 'version' attribute to a Port, the fact that we've got an attribute for Topologies is immaterial. It should be treated in the same manner as if they'd added a 'is_on_fire' attribute to a Node. Same deal with the relationships. If someone adds a "hasTopology" for a service or whatever, then it's treated the same as if they'd added a "hasPortIfOnFire" relationship to a Node.