Adrian Kuhn wrote: No problem. I will do that the end of this week or next week. I do have a list of remarks on the mess of FM3 / MSE that is currently online. There doesn't seem to be too much consistency anymore, since the things that have been changing recently. At the office I have a bigger list of things; but things that I currently remember: - you state that those primitive objects are the only ones which shouldn't necessarily be defined in a package. I seem to recall that at some point we had entries like: (MSE.Class (back then it was still mse) (id:...) (name: Boolean)) as a toplevel statement; not in a package; to which we referred by id. Now all of a sudden I see in the FM3 file that you have used ref: (which looks like the primitive: in the EMOF version), but which is not defined in FM3. Does ref: mean that you do some lookup, or is this only for primitives, or ... where does it come from? And where -did- those primitive declarations go? They don't have to be declared anymore? I didn't understand this by just looking at the available specification online. Oh, and then... object is not a primitive type. Which means that if that is the definition; object should be declared... so I guess you don't have to write "the objects known to the reader" (reserved instances as you call them), and are ref:-able? - I started noticing while implementing my python-version of FM3, that you only specify that the field attributes of class can not contain attributes of the allAttributes of the superclass. Does this allow for attributes to have duplicates? I haven't seen the word "set" on that page. It just states "multivalued" which doesn't say anything about the actual values. Which is normal; because for normal models we probably -do- want to be able to have duplicates. - I just noticed that FAMIX3.0 spec is only online in EMOF? (or at least, that is the only version I found in a quick search) Shouldn't we at least have an FM3 version somewhere? Then the "good" news: today I finished a prototype implementation of an FM3 metarepository builder, which unlike the smalltalk version, builds the repository in single pass, and doesn't use 10 different dictionaries for building it up. Actually, the builder itself hasn't got any dictionary and fills up the model from scratch without doing intermediate things itself. Actually; I guess that we can do a similar single-pass MSE-reader for smalltalk (and maybe python too); which shouldn't be too difficult if we use "become" to swap "most-specific instances known up to a certain point" by "more specific instances". For FM3 that isn't an issue since at all times we know the exact type of what should be were, even if it isn't read yet. The metarepository builder is something special anyway :) Then at some point I might put in that opposite/derived/type story I told Adrian and Doru; if I am working on this anyway. For those who are not following and still reading (you must be really bored :P) (... (name "type1") (property (name "prop1") (derived true) (type "type2") (opp "prop2") ....) (... (name "type2") (property (name "prop2") (type "type1") (opp "prop1") ....) has duplicated info and could be reduced to: (... (name "type1") (property (name "prop1") (type "type2") (opp "prop2") ....) (... (name "type2") (property (name "prop2") ....) -> if you link to a prop of another type; that prop of that other type automatically links back to you (prop) with as type, the class in which that prop was defined. The one stating the opposite link is automatically the derived version. 1 special case: if a prop has itself as opposite (i.e. the opposite property of FM3.Property), it is not derived. This comes from the fact that while defining the original drafts for FAMIX3.0, I had to type out this info. And having to copy all that data over and over again... is quite a hassle. And well, duplicated info is never good anyway. Enough for one mail. Cheers, Toon