[Nml-wg] Extensibility

[Aaron Brown]

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.

We could probably get away with "NMLv1 parsers SHOULD ignore undefined attributes or relationships. NMLv1 generators MAY add attributes or relationships outside of the NMLv1 specification, but MUST NOT assume that other parsers will handle those attributes or relationships.", and the cases above would simply implicitly be part of this.

Cheers,
Aaron

> 
> Regards,
> Freek
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

ESCC/Internet2 Joint Techs
July 15-19, 2012 - Palo Alto, California
Hosted by Stanford University
http://events.internet2.edu/2012/jt-stanford/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120706/c0dd6479/attachment.html>