Serial compound relations: "last" call on concepts, part 1
Hi, At the previous call I was assigned the following work item (someone my absence from the call put me on the "I volunteer" list; at least that's what I was told afterwards :~O )
* Serial Compound Relations Syntax Freek put this on the agenda to close our discussion we had on the mailinglist. We had a too small group to make a decision on this. It would also help if we had a summary of the discussion until right now. Freek, could you provide that?
I have not caught up with all yet, but like some sort of workgroup last call for the following decision: There are three ways to describe a serial compound relation (thus the segmentation of a end-to-end link on a single layer) 1. It should be possible to say that a link A is a segment of another link E. 2. It should be possible to say that a link A has sink port X, and port link has source port X, meaning that link A is directly connected to link B. 3. It should be possible to say that a link A is followed by the "next" link B. 4. It is possible to say that a link A is the "first" link (segment) of a link E (the end-to-end link), and it is possible to say that a link D is the "last" link (segment) of a link E. 5. We only use the concept of "links", not of "segments" or "end-to-end link", it is the _relation_ that determine if some link is a "segment" of another link or not. (Note that this explicitly chooses the "first", "next", "last" relations as proposed by Aaron, not the numbered (1,2,3,...) relations as proposed by Freek.) With the following additions: Ad 2. In case 2, links that are cross connects within a device MUST be listed. Ad 3. In case 3, cross-connect links MAY/MUST(?) be skipped, meaning that in the situation: - sink of link A is port X - source of link C is port X - link C is of type "crossconnect" - sink of link C is port Y - source of link B is port Y then one can (MUST? MAY?) say that: - the "next" link following link A is link B instead of: - the "next" link following link A is link C (of type crossconnect) - the "next" link following link C is link B There is more to say on this topic (e.g. the above does not discuss syntax in any way), but the above is what I have seen in proposals and examples. I now like to ratify or reject this by the working group. Please mail your comment (even if it is just "OK") within three weeks. We particular like input on addendum 3. (is that a "MAY" or a "MUST"?) Thanks, Freek
On Feb 1, 2011, at 8:24 PM, Freek Dijkstra wrote:
Hi,
At the previous call I was assigned the following work item (someone my absence from the call put me on the "I volunteer" list; at least that's what I was told afterwards :~O )
* Serial Compound Relations Syntax Freek put this on the agenda to close our discussion we had on the mailinglist. We had a too small group to make a decision on this. It would also help if we had a summary of the discussion until right now. Freek, could you provide that?
I have not caught up with all yet, but like some sort of workgroup last call for the following decision:
There are three ways to describe a serial compound relation (thus the segmentation of a end-to-end link on a single layer)
1. It should be possible to say that a link A is a segment of another link E. 2. It should be possible to say that a link A has sink port X, and port link has source port X, meaning that link A is directly connected to link B. 3. It should be possible to say that a link A is followed by the "next" link B. 4. It is possible to say that a link A is the "first" link (segment) of a link E (the end-to-end link), and it is possible to say that a link D is the "last" link (segment) of a link E. 5. We only use the concept of "links", not of "segments" or "end-to-end link", it is the _relation_ that determine if some link is a "segment" of another link or not.
(Note that this explicitly chooses the "first", "next", "last" relations as proposed by Aaron, not the numbered (1,2,3,...) relations as proposed by Freek.)
With the following additions:
Ad 2. In case 2, links that are cross connects within a device MUST be listed. Ad 3. In case 3, cross-connect links MAY/MUST(?) be skipped, meaning that in the situation: - sink of link A is port X - source of link C is port X - link C is of type "crossconnect" - sink of link C is port Y - source of link B is port Y then one can (MUST? MAY?) say that: - the "next" link following link A is link B instead of: - the "next" link following link A is link C (of type crossconnect) - the "next" link following link C is link B
There is more to say on this topic (e.g. the above does not discuss syntax in any way), but the above is what I have seen in proposals and examples. I now like to ratify or reject this by the working group.
Please mail your comment (even if it is just "OK") within three weeks. We particular like input on addendum 3. (is that a "MAY" or a "MUST"?)
OK Cheers, Aaron
Thanks, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Hello, On 02/02/2011 02:24, Freek Dijkstra wrote:
Please mail your comment (even if it is just "OK") within three weeks. We particular like input on addendum 3. (is that a "MAY" or a "MUST"?)
I think it's fine. However, I think that we should not have things implicit in the description. I would prefer an explicit and consistent description, this makes it easier for the implementation as well. Jeroen.
Peoples, I started to capture the different example XML instance documents into a reference XML schema but have a number of questions. The first question is the use of id and idRef attributes that appear in the examples. I had assumed these were standard XML attributes, however, the URN values in the example XML are not compatible with the XML ID and IDREF attribute types (":" are not allowed in NCNames). Can I use the XML base anyURI type for this? Thank you, John.
Hi John; We choose to define our own id and idRef elements because the semantics of the native XML definitions only allowed the scope to be within a single XML document. Since many of the topology elements are long lived, we need semantics that could allow references between documents. Hope this helps; -jason On 2/23/11 2:45 AM, John MacAuley wrote:
Peoples,
I started to capture the different example XML instance documents into a reference XML schema but have a number of questions. The first question is the use of id and idRef attributes that appear in the examples. I had assumed these were standard XML attributes, however, the URN values in the example XML are not compatible with the XML ID and IDREF attribute types (":" are not allowed in NCNames). Can I use the XML base anyURI type for this?
Thank you, John.
On 2/1/11 8:24 PM, Freek Dijkstra wrote:
Hi,
At the previous call I was assigned the following work item (someone my absence from the call put me on the "I volunteer" list; at least that's what I was told afterwards :~O )
* Serial Compound Relations Syntax Freek put this on the agenda to close our discussion we had on the mailinglist. We had a too small group to make a decision on this. It would also help if we had a summary of the discussion until right now. Freek, could you provide that?
I have not caught up with all yet, but like some sort of workgroup last call for the following decision:
There are three ways to describe a serial compound relation (thus the segmentation of a end-to-end link on a single layer)
1. It should be possible to say that a link A is a segment of another link E. 2. It should be possible to say that a link A has sink port X, and port link has source port X, meaning that link A is directly connected to link B. 3. It should be possible to say that a link A is followed by the "next" link B. 4. It is possible to say that a link A is the "first" link (segment) of a link E (the end-to-end link), and it is possible to say that a link D is the "last" link (segment) of a link E. 5. We only use the concept of "links", not of "segments" or "end-to-end link", it is the _relation_ that determine if some link is a "segment" of another link or not.
(Note that this explicitly chooses the "first", "next", "last" relations as proposed by Aaron, not the numbered (1,2,3,...) relations as proposed by Freek.)
With the following additions:
Ad 2. In case 2, links that are cross connects within a device MUST be listed. Ad 3. In case 3, cross-connect links MAY/MUST(?) be skipped, meaning that in the situation: - sink of link A is port X - source of link C is port X - link C is of type "crossconnect" - sink of link C is port Y - source of link B is port Y then one can (MUST? MAY?) say that: - the "next" link following link A is link B instead of: - the "next" link following link A is link C (of type crossconnect) - the "next" link following link C is link B
There is more to say on this topic (e.g. the above does not discuss syntax in any way), but the above is what I have seen in proposals and examples. I now like to ratify or reject this by the working group.
Please mail your comment (even if it is just "OK") within three weeks. We particular like input on addendum 3. (is that a "MAY" or a "MUST"?)
Tentative OK, I would like to see a concrete example personally. -jason
W dniu 2011-02-02 02:24, Freek Dijkstra pisze:
Hi,
At the previous call I was assigned the following work item (someone my absence from the call put me on the "I volunteer" list; at least that's what I was told afterwards :~O )
* Serial Compound Relations Syntax Freek put this on the agenda to close our discussion we had on the mailinglist. We had a too small group to make a decision on this. It would also help if we had a summary of the discussion until right now. Freek, could you provide that? I have not caught up with all yet, but like some sort of workgroup last call for the following decision:
There are three ways to describe a serial compound relation (thus the segmentation of a end-to-end link on a single layer)
1. It should be possible to say that a link A is a segment of another link E. 2. It should be possible to say that a link A has sink port X, and port link has source port X, meaning that link A is directly connected to link B. 3. It should be possible to say that a link A is followed by the "next" link B. 4. It is possible to say that a link A is the "first" link (segment) of a link E (the end-to-end link), and it is possible to say that a link D is the "last" link (segment) of a link E. 5. We only use the concept of "links", not of "segments" or "end-to-end link", it is the _relation_ that determine if some link is a "segment" of another link or not.
(Note that this explicitly chooses the "first", "next", "last" relations as proposed by Aaron, not the numbered (1,2,3,...) relations as proposed by Freek.)
With the following additions:
Ad 2. In case 2, links that are cross connects within a device MUST be listed. Ad 3. In case 3, cross-connect links MAY/MUST(?) be skipped, meaning that in the situation: - sink of link A is port X - source of link C is port X - link C is of type "crossconnect" - sink of link C is port Y - source of link B is port Y then one can (MUST? MAY?) say that: - the "next" link following link A is link B instead of: - the "next" link following link A is link C (of type crossconnect) - the "next" link following link C is link B
There is more to say on this topic (e.g. the above does not discuss syntax in any way), but the above is what I have seen in proposals and examples. I now like to ratify or reject this by the working group.
Apologize for late response. I wonder if stressing that the the link C is of type crossconnect is so important to treat it a different way (maybe it is)? For me it's just a link even if physically different from A and B. It may contain a property saying that it's crossconnect. So I would prefer the chain A->C->B instead of A->B. But also I'm fine using two approaches. regards, Roman
Please mail your comment (even if it is just "OK") within three weeks. We particular like input on addendum 3. (is that a "MAY" or a "MUST"?)
Thanks, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
participants (6)
-
Aaron Brown -
Freek Dijkstra -
Jason Zurawski -
Jeroen van der Ham -
John MacAuley -
Roman Łapacz