[udm-dev] Udm meeting memo

[Endre Magyari]

Hello Attila,


> In summary, we have agreed on the following:
> 1, The current namespace support in udm_ns is not viable in the
> long-term, because it does not have clean and straightforward support
> for non-namespace usage scenarios (which is still in active use).
> 2, We need to redesign the namespace feature, and reimplement the
> corresponding code with the following rule in mind:
> 	If a user does not use namespaces, then Udm must generate the
> same set of artifacts (e.g. udm xml file, DS-API, xsd, etc.) as before.
> 3, This change requires putting back the
> Diagram-{Class,Association,Composition} containment relationships into
> UmlinUml, and modifying the udm core libraries to reflect these changes.
> 4, We must restore the non-namespace functionality completely.


Ok, should I understand that for namespace scenarios the current design is  
OK ?

> We realize that it will take several months to complete these changes.

I never said several months. A month is enough.

> In the meantime, we would like to start testing the existing udm_ns
> version, point out its weaknesses, so that we can learn from the faults,
> and take the accumulated learnings into the new design. Currently, we
> are aware of two limitations that prevent us from starting the tests.
> 1, smart namespace generation feature
> 2, Discrepancy of the Udm Xml file with GME model files: since every udm
> xml file contains a namespace, how can they used to validate/manipulate
> GME model files, obviously with GME not having namespace support.
>
> Please give your thoughts on these issues. If you could fix these two
> problems, then we could start the extensive testing of udm_ns on the
> next week.

1.) - I can fix this by Monday
2.) - I'm not sure I understand the connection with UDM XML files and GME  
models.
Are you reffering to UML Udm XML files or DS Udm XML files ( a result of  
UDM DOM Backend ) ?

In case of UML UDM XML files, I don't see how they are related to GME  
models.
In case of DS UDM XML files, each object clearly belongs to a XML  
namespace defined by   an .xsd file for that namespace.
in the MGA backend, this is implemented with a registry key/value pair.  
(key = __udm_namespace)




> We believe that udm_ns is now fairly close to the stage where it can be
> used with reasonable confidence.

As I said, all tests are green now.

> Specifically, our hope/plan is that we can prove that udm_ns is (1)
> fully backward compatible, and (2) fullfills the namespace requirements
> completely, in 3-4 weeks.

Isn't (2) proved at this moment?


> If we cannot show this, than we have to discard the changes, and start
> adding the namespace feature from scratch (e.g. from old udm).
>
> Meanwhile, we can start redesigning the namespace feature with the above
> goals in mind. We'd also like to have you share your design ideas with
> us prior to implementing them.
> We can help not only in the desing, but in the implementation, as well.

I'd further investigate the possibility to have a clear and simple (the  
simpler, the better) design:

1. All classes shoud belong (semantically) to a namespace, even if there  
is one special namespace (root namespace), with special API mapping (the  
old C++ API syntax).
    Let me continue with Gabor's parallel, if you look at the  
C++ namespaces/classes , all classes belong to a namespace.
    And of course, there is a root namespace, but still, internally it is a  
(special) namespace.
    In case of C++, you don't have some classes in namespaces, and some  
classes in "no namespace". You have them in the "root namespace" which is  
still a namespace.

2. reintroducing the containment relationships Diagram - {Class,  
Association and Composition} will lead to a lot of ambigous and  
complicated code resulting from an ambigous parent() call, which does not  
return Uml::Namespace, but Udm::Object and the user will always have  to  
check runtime for it's type.
It's also not clear what is the difference between the contaiment  
relationships Namespace - {Association, Composition} and Diagram -  
{Association, Composition}. I believe nothing, so why should we have this  
ambiguity in the modelling environment and in UmlInUml.


As a conclusion, I'd investigate the idea of a special namespace, let us  
call it "root namespace", and for non-namespace scenarios I'd consider all  
defined classes in that "root namespace". Internally, I'd keep all classes  
strongly tied to a namespace, I believe this makes UDM and UDM  
applications simpler, as opposed to a hierarchy when Classes are either in  
Namespaces or in Diagrams.

I believe this does not interfere with backward compatibility, as defined  
by Gabor: "old code works." Btw, this is achieved as of now.

Your proposed changes would make UmlinUml (the core of Udm) more  
complicated and ambigous.
We should keep it simple and straightforward, as it is now or as it is in  
old UDM.

Do you think that the idea of a "special namespace" could work?


If so, I already have an idea, we could use unnamed namespaces (namespace  
with no name) as a "special namespace".
This also solves the following generation issue:

Currently if there is a single namespace in the Uml diagram, we don't  
generate the extra C++ namespace, to provide backward compatibility:

So, instead of

namespace LampDiagram
{
	namespace LampDiagram
	{
		Uml::Namespace meta;
		class Lamp;
	}
}

we generate

namespace LampDiagram
{
	Uml::Namespace meta;
	class Lamp;
}

in case of a single Namespace in Diagram. This does not break existing  
code.


Instead, we could generate an unnamed C++ namespace :

namespace LampDiagram
{
	namespace
	{	
		Uml::Namespace meta;
		class Lamp;
	}
}


The great thing is that :
	1. C++ supports supports such unnamed namespaces
	2. LampDiagram::Lamp syntax would still work


Taking advantage of C++'s unnamed namespaces, we could solve this issue  
like this:

1. uml2xml: classes without a namespace will be placed in an unnamed  
namespace. <Uml:Namespace> <class name ....> </Uml:Namespace>
2. udm.exe would be extremly straigtforward in API generation: for each  
Uml Namespace a C++ namespace would be generated with it's name. (thus, a  
UML namespace with no name would be mapped to a C++ unnamed namespace)



Thanks,
Endre