[Nml-wg] Extensibility

[Freek Dijkstra]

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?

Regards,
Freek