Re: self describing MOF?



Date view Thread view Subject view Author view Attachment view

From: Laurence Tratt (laurie@tratt.net)
Date: Tue 20 Apr 2004 - 14:26:20 BST


On Tue, Apr 20, 2004 at 01:33:16PM +0200, Alexander Rupsch wrote:

Dear Alexander,

> The  statement "MOF is self describing" is some kind of fuzzy to me, so I
> need enlightenment.
>
> The spec says: "... the MOF Model is formally defined using its own
> metamodeling constructs."
>
> Defining or describing to me means, explaining on thing using some other
> things. If I have the constructs A, B, C, that means for example "A = B" or
> "B = C + A" would be a description which contains new information. "A = A"
> does not. That is different to be elemental.
>
> Is it really possible to express any MOF construct with some other MOF
> constructs without using some elemental concepts like "this is a"?
>
> For example "Generalizable Element" is a  generalization of "Namespace" but
> it can't be because Namespace is not a "Generalizable Element". Yes if I
> model that in MOF it could be, because I can use a "Class" to express
> "Namespace" and the (in this case) meta-construct "Class" can be
> generalized. But I'm defining MOF so can I use it? This is chicken and egg.
>
> I understand that this not matter to the usability of MOF since chicken and
> eggs are happy being (if keeping in their natural environment).

It's an interesting question. Chickens are generally happy because they are
oblivious to the state of the world beyond the piece of feed two inches from
their beak. In no way would I suggest standards committees work in the same
fashion. One thing to bear in mind is that in the upcoming 2.0 standards,
political fudgery has split MOF into EMOF and CMOF which further muddies
already murky waters. But let's ignore that for this discussion.

Firstly, MOF isn't formally defined in a manner that any mathematician or
logician worth their salt would recognise.

Secondly, MOF relies on lots of external concepts, but these are mostly
defined in natural language. In other words, the definition isn't self
contained. One has, at some point, to rely on either fundamental assumptions
or to bring in an external system (which, at some point, will have such
fundamental assumptions) otherwise nothing has any real basis.

Thirdly, what the spec really means by "formally defined using its own
metamodeling constructs" is that MOF is the point at which the cycle in
metalevels is created. In essence if I as a user create a class C, that's an
instance of UML's Class construct, which is an instance of MOF's Class
construct. Because we don't want to go on creating modelling languages for
ever (we'd run out of three letter acronyms eventually), we say that MOF's
Class construct is an instance of itself. So although one can say "what is
the Class of the Class of the Class of MOF's Class?" and so on, one will
only ever got back the answer "MOF Class". The constraints on what a valid
MOF Class look like apply equally to the MOF Class itself.

MOF essentially constrains what instances of it look like, but isn't capable
of creating such instances itself. It's interesting at this point to have a
look at similar systems which are capable of creating instances, because
initially it seems very confusing and non-obvious, but at some point
"clicks" as to how this stuff can actually work in a practical running
system. ObjVLisp is probably the granddaddy of all such approaches and I
heartily reccomend digging up some of the relevant papers (look in the pUML
archives for links to them). Here's an example in my Converge language.
First the full code (the __of__ slot of an object tells you what this object
is an instance of):

"""
import Sys

class My_Class:
	pass

func main():
	Sys.writeln("Class: ", Class)
	Sys.writeln("Object: ", Object)
	Sys.writeln("Class.__of__: ", Class.__of__)
	Sys.writeln("Object.__of__: ", Object.__of__)
	Sys.writeln("Class.__of__.__of__: ", Class.__of__.__of__)
	Sys.writeln("2: ", 2)
	Sys.writeln("2.__of__: ", 2.__of__)
	Sys.writeln("2.__of__.__of__: ", 2.__of__.__of__)
	Sys.writeln("My_Class: ", My_Class)
	Sys.writeln("My_Class.__of__: ", My_Class.__of__)
	Sys.writeln("My_Class(): ", My_Class())
	Sys.writeln("My_Class().__of__: ", My_Class().__of__)
"""

and then the output:

"""
Class: <Class Class>
Object: <Class Object>
Class.__of__: <Class Class>
Object.__of__: <Class Class>
Class.__of__.__of__: <Class Class>
2: 2
2.__of__: <Class Int>
2.__of__.__of__: <Class Class>
My_Class: <Class My_Class>
My_Class.__of__: <Class Class>
My_Class(): <Object@1008155884>
My_Class().__of__: <Class My_Class>
"""

One can go on and on exploring the system like this to ones heart is
content.

One of things this example shows is that the meta-level cycle is created in
Converge because during a torturous bootstrapping phase that is invisible
from the user, one of the main things is that the object Class is defined to
be an instance of itself; thus the chicken and egg situation is resolved.
Once that's done, and by the time any user code gets created, everything
works nice and neatly from the users point of view.

I hope this helps in some way!

Yours,


Laurie
-- 
http://tratt.net/laurie/

Date view Thread view Subject view Author view Attachment view