Hi, For most of the NML model we have made it so that there is only one relation defined between two objects. However, Richard spotted a situation where we do have two: - A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better. Jeroen.
W dniu 2013-03-12 20:50, Jeroen van der Ham pisze:
Hi,
For most of the NML model we have made it so that there is only one relation defined between two objects. However, Richard spotted a situation where we do have two:
- A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port
Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better. Fine be me. TO DO for the schema.
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On Mar 13, 2013, at 8:47 AM, Roman Łapacz <romradz@man.poznan.pl> wrote:
W dniu 2013-03-12 20:50, Jeroen van der Ham pisze:
Hi,
For most of the NML model we have made it so that there is only one relation defined between two objects. However, Richard spotted a situation where we do have two:
- A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port
Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better. Fine be me. TO DO for the schema.
Ditto Cheers, Aaron
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 12-03-2013 15:50, Jeroen van der Ham wrote:
For most of the NML model we have made it so that there is only one relation defined between two objects. However, Richard spotted a situation where we do have two:
- A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port
Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better.
Very good catch by Richard. The second is more than "slightly" more informative; I'd even dare to say it contains vital additional information about the direction. So I suggest we should make the second form a MUST, and the first a SHOULD NOT. (Admittedly, the first form does no harm at all, and is useful. The reason for the strong SHOULD NOT is that it brings a risk of incompatibility if one organisation uses the first form, and another organisation uses the second form) Freek
Hi, On 13 Mar 2013, at 10:07, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
So I suggest we should make the second form a MUST, and the first a SHOULD NOT. (Admittedly, the first form does no harm at all, and is useful. The reason for the strong SHOULD NOT is that it brings a risk of incompatibility if one organisation uses the first form, and another organisation uses the second form)
That is already covered by the first MUST. The SHOULD NOT would mean that we change the inherited behaviour of the Switching Service. If we keep that as a SHOULD, and the hasInboundPort as MUST, things work out. Jeroen.
On 13-03-2013 10:37, Jeroen van der Ham wrote:
On 13 Mar 2013, at 10:07, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
So I suggest we should make the second form a MUST, and the first a SHOULD NOT. (Admittedly, the first form does no harm at all, and is useful. The reason for the strong SHOULD NOT is that it brings a risk of incompatibility if one organisation uses the first form, and another organisation uses the second form)
That is already covered by the first MUST. The SHOULD NOT would mean that we change the inherited behaviour of the Switching Service. If we keep that as a SHOULD, and the hasInboundPort as MUST, things work out.
You're correct. If you could make a suggest what text to add/change/remove, that would be great! Freek
On 13 Mar 2013, at 10:39, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 13-03-2013 10:37, Jeroen van der Ham wrote:
On 13 Mar 2013, at 10:07, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
So I suggest we should make the second form a MUST, and the first a SHOULD NOT. (Admittedly, the first form does no harm at all, and is useful. The reason for the strong SHOULD NOT is that it brings a risk of incompatibility if one organisation uses the first form, and another organisation uses the second form)
That is already covered by the first MUST. The SHOULD NOT would mean that we change the inherited behaviour of the Switching Service. If we keep that as a SHOULD, and the hasInboundPort as MUST, things work out.
You're correct.
If you could make a suggest what text to add/change/remove, that would be great!
I'm proposing to add the following to the Schema description of SwitchingService: The \emph{SwitchingService} inherits the \emph{hasPort} relation from \emph{Service}. The \emph{hasInboundPort} and \emph{hasOutboundPort} can be seen as more specific instantiations of the \emph{hasPort} relation, so these are preferred. Jeroen.
On 13-03-2013 10:55, Jeroen van der Ham wrote:
I'm proposing to add the following to the Schema description of SwitchingService:
The \emph{SwitchingService} inherits the \emph{hasPort} relation from \emph{Service}. The \emph{hasInboundPort} and \emph{hasOutboundPort} can be seen as more specific instantiations of the \emph{hasPort} relation, so these are preferred.
That doesn't seem correct. hasPort, in the current schema, is NOT a "more general" variant of "hasInboundPort" or "hasInboundPort" (although we previously had something like that). Instead, "hasPort" is used for specifying items in a Group: e.g. <PortGroup A-D> 'hasPort' <Port A>. In particular, the domain of a hasPort relation may not be a Service. Freek
On 13 Mar 2013, at 11:02, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 13-03-2013 10:55, Jeroen van der Ham wrote:
I'm proposing to add the following to the Schema description of SwitchingService:
The \emph{SwitchingService} inherits the \emph{hasPort} relation from \emph{Service}. The \emph{hasInboundPort} and \emph{hasOutboundPort} can be seen as more specific instantiations of the \emph{hasPort} relation, so these are preferred.
That doesn't seem correct.
hasPort, in the current schema, is NOT a "more general" variant of "hasInboundPort" or "hasInboundPort" (although we previously had something like that). Instead, "hasPort" is used for specifying items in a Group: e.g. <PortGroup A-D> 'hasPort' <Port A>.
In particular, the domain of a hasPort relation may not be a Service.
Right, my apologies, this should of course be about the hasService relation that a Port object has. So, it should be like this: A \emph{Port} object can have a \emph{hasService} relation, however the \emph{SwitchingService} defines a more specific relation \emph{hasInboundPort} / \emph{hasOutboundPort} relation to a \emph{Port} object. The latter relation is preferred over the \emph{hasService} relation of the \emph{Port} to the \emph{SwitchingService}.
On 13-03-2013 11:07, Jeroen van der Ham wrote:
A \emph{Port} object can have a \emph{hasService} relation, however the \emph{SwitchingService} defines a more specific relation \emph{hasInboundPort} / \emph{hasOutboundPort} relation to a \emph{Port} object. The latter relation is preferred over the \emph{hasService} relation of the \emph{Port} to the \emph{SwitchingService}.
Thanks, good text. I assume it will go in section '2.2.10 hasService'? Freek
On 13 Mar 2013, at 11:15, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 13-03-2013 11:07, Jeroen van der Ham wrote:
A \emph{Port} object can have a \emph{hasService} relation, however the \emph{SwitchingService} defines a more specific relation \emph{hasInboundPort} / \emph{hasOutboundPort} relation to a \emph{Port} object. The latter relation is preferred over the \emph{hasService} relation of the \emph{Port} to the \emph{SwitchingService}.
Thanks, good text. I assume it will go in section '2.2.10 hasService'?
Will do, I was thinking to add it also to the SwitchingService section. Jeroen.
On 13-03-2013 11:21, Jeroen van der Ham wrote:
On 13 Mar 2013, at 11:15, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 13-03-2013 11:07, Jeroen van der Ham wrote:
A \emph{Port} object can have a \emph{hasService} relation, however the \emph{SwitchingService} defines a more specific relation \emph{hasInboundPort} / \emph{hasOutboundPort} relation to a \emph{Port} object. The latter relation is preferred over the \emph{hasService} relation of the \emph{Port} to the \emph{SwitchingService}.
Thanks, good text. I assume it will go in section '2.2.10 hasService'?
Will do, I was thinking to add it also to the SwitchingService section.
If you think it is useful, you can add a small note or reference there. That's what I usually tried (although there may still some duplicate text in some places) Freek
W dniu 2013-03-13 15:07, Freek Dijkstra pisze:
On 12-03-2013 15:50, Jeroen van der Ham wrote:
For most of the NML model we have made it so that there is only one relation defined between two objects. However, Richard spotted a situation where we do have two:
- A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port
Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better. Very good catch by Richard.
The second is more than "slightly" more informative; I'd even dare to say it contains vital additional information about the direction.
So I suggest we should make the second form a MUST, and the first a SHOULD NOT. (Admittedly, the first form does no harm at all, and is useful. The reason for the strong SHOULD NOT is that it brings a risk of incompatibility if one organisation uses the first form, and another organisation uses the second form)
If you state SHOULD NOT then it's better to remove it from the schema. It's better to do it now, when NML is not really used by some applications, then later. Roman
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 13-03-2013 10:39, Roman Łapacz wrote:
- A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port
Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better.
If you state SHOULD NOT then it's better to remove it from the schema. It's better to do it now, when NML is not really used by some applications, then later.
hasService is used for other relations, including from a (server layer) Port to an AdaptationService. Removing hasService would require us to introduce a new relation type for that relation as well. I think we're too far into the document publication process to make such a change. Freek
W dniu 2013-03-13 15:43, Freek Dijkstra pisze:
On 13-03-2013 10:39, Roman Łapacz wrote:
- A Port can have a "hasService" relation to a SwitchingService - A SwitchingService can have a "hasInboundPort" relation to a Port
Perhaps it would make sense to suggest a preference that one of them must be there and that the other is optional. The second relation is slightly more informative, so that is probably better. If you state SHOULD NOT then it's better to remove it from the schema. It's better to do it now, when NML is not really used by some applications, then later. hasService is used for other relations, including from a (server layer) Port to an AdaptationService. Removing hasService would require us to introduce a new relation type for that relation as well. I think we're too far into the document publication process to make such a change.
Hmm, right (checked in the example section). Roman
Freek
participants (4)
-
Aaron Brown -
Freek Dijkstra -
Jeroen van der Ham -
Roman Łapacz