Jason Zurawski wrote:
The above leads to three scenario's in mind where it may be prudent to mix namespaces in a single message: - core topology with technology specific (Ethernet, IP, ..) namespaces. This is probably the weakest use case, as it is possible to add the core topology concepts to each technology specific namespace (e.g. using chameleon namespaces) - topology namespace with geo namespace - topology namespace with an application-specific namespaces (eg. topology + NSI for path finding, or topology + NMC for monitoring).
You describe all of the things that I (and others in SLC) were arguing for all along - the ability to extend the base ideas concepts into new use cases through the use of namespace extensions. I will make one quibble on the above - I would argue its important to make the 'base' set minimal, e.g. 'ethernet', 'ip', etc. are not *in* the base, these are extensions *of* the base.
I think we are in agreement with these points from the start. What I'm not sure we agree upon is how to implement this. The way this is done in NMC (using chameleon namespaces) is certainly not the only way to accomplish this. On top of my head, I can think of the following design patterns that accomplish the same thing: * Base + extensions * Object composition * Instances can be instance-of multiple classes * Subclassing * Pointer to base class in schema description * Chameleon namespaces * Pointer to base class in messages itself For example, in NDL we first played with a method where the technology-specific schema were INSTANCES of the base schema, thus not a SUBCLASS of the base schema, and network resources has-a property consisting of one of these technology-specific instances (we could do this, because in RDF, a Resource can be a Class and an Instance at the same time). Later, we settled on a method where network resources where INSTANCES of two distinct classes: both an instance of a base class (eg. rdf:type ndl:Interface) as well as an instance of a technology-specific class (e.g. rdf:type wdm:FiberNetworkElement). (In RDF, a Resource can be a instance of multiple classes, kind of like the Object composition design pattern). My gut feeling is that Subclasses is a very common method, so I'm inclined to use that for NML. However, since Chameleon namespaces are uncommon, I would rather settle for a more common design pattern. Now, a problem may be that we're lacking a real ontology designer. We're all network experts here. It seems we have know how to make ontologies (me and Jeroen in RDF, you and Roman in XML), and have found a few things that worked well for us. However, I known I'm not well versed with all the ins and outs of all ontology design concepts (franky, I had to Google the names of a few of the above design pattern, and fear I still have it wrong, so I resorted to use my own wording). I'm a bit at loss right now what the best way forward is -- we seem to argue a great deal about the syntax, not about the underlying network concepts. Unfortunately, it does matter, since the choices we make in syntax have consequences for e.g. the extensibility. Would it help to more clearly describe our requirements? E.g. what kind of extensibility we want (e.g. make a backward- or forward-compatible version 2 of the base later; add more technologies without touching the base schema; add more relation with or without touching the base schema; mix with other schemata, ...) Regards, Freek