[Nml-wg] First draft of NML Schema document

[Roman Łapacz]

W dniu 2012-11-29 13:01, Jeroen van der Ham pisze:
> Hi,
>
> On 20 Nov 2012, at 15:49, Roman Łapacz <romradz at man.poznan.pl> wrote:
>
>> Just few comments/observations:
>>
>> 1) 1.1. "...Finally, you will not find a definition for the terms Network or capacity in this document"
>> RL: ...but there is a definition (or piece of information) of Network object in 2.1.1. This might be misleading for a reader.
> There is not really a definition of Network Object there. All it says is that it is an abstract class. So I don't really see a problem there. Even if we were to include a definition for Network Object there, it is very likely going to contain the word "Network", so it is still not going to provide a definition of "Network".
>
>> 2) 2.1.1. "...The meaning of the version attribute is only defined for specific cases (in objects of the Topology class), and should not be used in other objects. Clients that receive a version attribute for a non-Topology object should ignore that attribute. "
>>   RL: So why not to move this attribute to the Topology class? If we want to keep it in the Network object for possible extension in the future then it should be indicated clearly in the text.
> I think that that is a valid point. Doing this should not stop us from adding "version" to other objects in the future, right?
>
>> 3) RL: Do we really need Service and Group elements? They don't have any attributes or relations. For example, Node, Port and Link don't have Element abstract class above. Inconsistency?
> They do, the Network Object.
> I agree it's not the most elegant solution, the intention is to have this as an extension point for other services. We have not done so yet, but the NSI connection service could be explained as something similar. Or a Monitoring service.

I see your point but an empty abstract class does not look nice. One 
could say that a services like AdaptationService could inherit directly 
form Network Object. Service does not bring any thing except a kind of 
category. But I'm not against to keep it.

Roman

>
>> 4) RL: Do we need the list of attributes in 2.1.2 inherited from Network abstract class (the same for other elements)? They are already described in 2.1.1.
> The idea about that is that each section stands on its own. You can look at one section and instantly know all there is to know about a single object.
>
> Jeroen.
>