Serialising vs modelling

[Alberto Micol]

> Indeed, to be clear about this, we shouldn't be concerned at this 
> modelling stage about the *method names* at all.  We should just be 
> interested in the data relationships, both activity and static.  
> Method names will largely depend on the conventions of the languages 
> being used - bear in mind we will probably have FORTRAN 
> implementations as well as Java. 


Thank you Martin!
We have to separate design and implementation as much as we can.

In the old days everybody was speaking COBOL, that was a modern thing,
the good thing, etc. etc. Now OO is the way, the good way. It is The 
Solution.
But tomorrow? (Yap I know, I'm getting older ...)

I love the RM document (Bob's one for the registry), it is plain english
you can take it, read it, understand it, and implement it the way you want.
And in 50 years, you will take it, you will be still able to read it, 
understand it
and, being a good archeologist, implement it to see how those chaps worked
so many years ago.

You may wonder: "Shall we really make an archeologist's life that easy?"
But even nowadays there are out there (and even on this chair I'm 
sitting now)
data providers who are not that familiar with OO (my fault I know, I'm 
working
on it ...) but that still have to implement things in a way or in the other.
No, I'm not saying we use FORTRAN here ... ;-) we actually use java.

But the point is that DMs should be designed first,
and without any particular programming flavour in mind.
Otherwise design and implementation get quite intertwined
(and indeed this is the impression I sometimes get on this mailing list).

Alberto