[Nml-wg] Multiple namespaces

[Freek Dijkstra]

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