Filter:
Any Freek Dijkstra Jeroen van der Ham
Closed
11/30/2012
11/30/2012 8:18 AM EST
Jeroen van der Ham
Status
Wait for Other
Completed
11/30/2012 8:18 AM EST
Jeroen van der Ham
Description
So far we have identified several different relations. We have defined them all
in a single direction (hasTopology, hasNode, hasPort, isSource, isSink, etc.).
The question now is whether we want to allow the inverse of relations as well.
An example of where this is necessary has been brought up by Aaron:
A client domain may want to correct locally how a Link is connected by them, but
this Link is originally described by the Provider. There are two options:
1) Allowing descriptions of idRefs:
<Link idRef="urn:ogf:network:provider.com:2012:LinkA">
<nml:Relation type="isSource">
<nml:Port id="urn:ogf:network:client.net:2012:PortA"/>
</nml:Relation>
</Link>
2) Allow inverse of isSource
<nml:Port id="urn:ogf:network:client.net:2012:PortA">
<nml:Relation type="hasSource">
<Link idRef="urn:ogf:network:provider.com:2012:LinkA"/>
</nml:Relation>
</nml:Port>
So far we have identified several different relations. We have defined them all
in a single direction (hasTopology, hasNode, hasPort, isSource, isSink, etc.).
The question now is whether we want to allow the inverse of relations as well.
An example of where this is necessary has been brought up by Aaron:
A client domain may want to correct locally how a Link is connected by them, but
this Link is originally described by the Provider. There are two options:
1) Allowing descriptions of idRefs:
<Link idRef="urn:ogf:network:provider.com:2012:LinkA">
<nml:Relation type="hasSource">
<nml:Port id="urn:ogf:network:client.net:2012:PortA"/>
</nml:Relation>
</Link>
2) Allow inverse of isSource
<nml:Port id="urn:ogf:network:client.net:2012:PortA">
<nml:Relation type="isSource">
<Link idRef="urn:ogf:network:provider.com:2012:LinkA"/>
</nml:Relation>
</nml:Port>
[edit]
My apologies, I used the wrong inverses for the original example. The example is
fixed now.
[/edit]
04/02/2012 4:00 AM EDT
Jeroen van der Ham
Status
Under discussion
Wait for Other
08/08/2012 10:01 AM EDT
Freek Dijkstra
Category
UML schema
XML syntax
08/08/2012 10:01 AM EDT
Freek Dijkstra
Description
So far we have identified several different relations. We have defined them all
in a single direction (hasTopology, hasNode, hasPort, isSource, isSink, etc.).
The question now is whether we want to allow the inverse of relations as well.
An example of where this is necessary has been brought up by Aaron:
A client domain may want to correct locally how a Link is connected by them, but
this Link is originally described by the Provider. There are two options:
1) Allowing descriptions of idRefs:
<Link idRef="urn:ogf:network:provider.com:2012:LinkA">
<nml:Relation type="hasSource">
<nml:Port id="urn:ogf:network:client.net:2012:PortA"/>
</nml:Relation>
</Link>
2) Allow inverse of isSource
<nml:Port id="urn:ogf:network:client.net:2012:PortA">
<nml:Relation type="isSource">
<Link idRef="urn:ogf:network:provider.com:2012:LinkA"/>
</nml:Relation>
</nml:Port>
[edit]
My apologies, I used the wrong inverses for the original example. The example is
fixed now.
[/edit]
Currently, and id is used in the XML parent element of a Relation, and a idRef
is used in the XML child element of a Relation:
Proposal:
- allow idRef in XML parent element of a Relation
- allow id in XML child element of a Relation
Current (remains allowed):
<nml:Link id="urn:ogf:network:provider.com:2012:PortA">
<nml:Relation type="isSource">
<nml:Port idRef="urn:ogf:network:client.net:2012:LinkA"/>
</nml:Relation>
</nml:Link>
Proposal (currently not allowed, may be allowed with this proposal):
<nml:Link idRef="urn:ogf:network:provider.com:2012:PortA">
<nml:Relation type="isSource">
<nml:Port id="urn:ogf:network:client.net:2012:LinkA"/>
</nml:Relation>
</nml:Link>
04/02/2012 10:13 AM EDT
Freek Dijkstra
Title
Allowing inverse relations
Allow idRef/id in parent/child of a Relation
04/02/2012 10:04 AM EDT
Freek Dijkstra
Description
So far we have identified several different relations. We have defined them all
in a single direction (hasTopology, hasNode, hasPort, isSource, isSink, etc.).
The question now is whether we want to allow the inverse of relations as well.
An example of where this is necessary has been brought up by Aaron:
A client domain may want to correct locally how a Link is connected by them, but
this Link is originally described by the Provider. There are two options:
1) Allowing descriptions of idrefs:
<Link idref="urn:ogf:network:provider.com:2012:LinkA">
<nml:Relation type="isSource">
<nml:Port id="urn:ogf:network:client.net:2012:PortA"/>
</nml:Relation>
</Link>
2) Allow inverse of isSource
<nml:Port id="urn:ogf:network:client.net:2012:PortA">
<nml:Relation type="hasSource">
<Link idref="urn:ogf:network:provider.com:2012:LinkA"/>
</nml:Relation>
</nml:Port>
So far we have identified several different relations. We have defined them all
in a single direction (hasTopology, hasNode, hasPort, isSource, isSink, etc.).
The question now is whether we want to allow the inverse of relations as well.
An example of where this is necessary has been brought up by Aaron:
A client domain may want to correct locally how a Link is connected by them, but
this Link is originally described by the Provider. There are two options:
1) Allowing descriptions of idRefs:
<Link idRef="urn:ogf:network:provider.com:2012:LinkA">
<nml:Relation type="isSource">
<nml:Port id="urn:ogf:network:client.net:2012:PortA"/>
</nml:Relation>
</Link>
2) Allow inverse of isSource
<nml:Port id="urn:ogf:network:client.net:2012:PortA">
<nml:Relation type="hasSource">
<Link idRef="urn:ogf:network:provider.com:2012:LinkA"/>
</nml:Relation>
</nml:Port>
03/29/2012 11:57 AM EDT
Freek Dijkstra
