Last, a long-time discussion: Roman spotted another issue:
The idRef="urn:ogf:network:nordu.net:2011:NORDUnet:org" does not appear to point at anything.
Freek replied:
Good catch. Frankly, the difference between id and idRef is never properly defined.
Roman clarified:
The idea of id and idRef was taken from NM/NMC and it's very useful to make distinction between definitions and references to those definitions.
I am aware of the origin, but will repeat my original rather firm statement: I've never seen a proper definition of the difference between the two. I've seen vague statements about origin, but I do not think that NML should use id/idRef to make statements about origin, if only for the reason that RDF does not contain id nor idRef. We did try to come up with a proper solution in https://forge.ogf.org/sf/go/artf6555 But that discussion was stranded by some terminology discussion in the related https://forge.ogf.org/sf/go/artf6553 (warning: long read) We did not get a consensus on the terminology, let alone find a solution how to encode it in either XML or RDF. I encourage you to come up with a good explanation what you want to distinguish between, and how you want to make that distinction -- both in XML and in RDF. I am looking forward to that proposal, but by lack thereof, I claim that we're better of without the id/idRef distinction, since it will only lead to confusion. Freek
On Jul 12, 2012, at 4:58 AM, Freek Dijkstra wrote:
Last, a long-time discussion:
Roman spotted another issue:
The idRef="urn:ogf:network:nordu.net:2011:NORDUnet:org" does not appear to point at anything.
Freek replied:
Good catch. Frankly, the difference between id and idRef is never properly defined.
Roman clarified:
The idea of id and idRef was taken from NM/NMC and it's very useful to make distinction between definitions and references to those definitions.
I am aware of the origin, but will repeat my original rather firm statement: I've never seen a proper definition of the difference between the two. I've seen vague statements about origin, but I do not think that NML should use id/idRef to make statements about origin, if only for the reason that RDF does not contain id nor idRef.
We did try to come up with a proper solution in https://forge.ogf.org/sf/go/artf6555
But that discussion was stranded by some terminology discussion in the related https://forge.ogf.org/sf/go/artf6553 (warning: long read)
We did not get a consensus on the terminology, let alone find a solution how to encode it in either XML or RDF.
I encourage you to come up with a good explanation what you want to distinguish between, and how you want to make that distinction -- both in XML and in RDF.
I am looking forward to that proposal, but by lack thereof, I claim that we're better of without the id/idRef distinction, since it will only lead to confusion.
I don't have a strong opinion on using id/idRef, as the method, but the idea is based around inheritance. As an example, you have port P defined in topology T. When referencing the port in topology S, I might want to override some of its properties (e.g. include our name for its Port). Another example might be the example I sent to the NSI list where I override the VLANs of the PortGroup so that the VLAN is chosen from a subset of the VLANs available. Using idRef allows an object to say "i'm defining some attributes of this network object. However, I inherit the rest of the attributes for this network object from the network object defined by the id I give in the idRef field". Cheers, Aaron
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
On 12-07-2012 17:23, Aaron Brown wrote:
I don't have a strong opinion on using id/idRef, as the method, but the idea is based around inheritance. As an example, you have port P defined in topology T. When referencing the port in topology S, I might want to override some of its properties (e.g. include our name for its Port).
So you are saying that the difference between id and idRef is that an object referenced by an id inherits some of the properties (such as Location) from the parent object, while an object referenced by an idRef does not inherit there properties? I do like this concept.
Another example might be the example I sent to the NSI list where I override the VLANs of the PortGroup so that the VLAN is chosen from a subset of the VLANs available.
You mean the example in http://www.ogf.org/pipermail/nsi-wg/2012-July/001984.html? I like this use case, and I based my proposal to the NSI-WG on your ideas: http://www.ogf.org/pipermail/nsi-wg/2012-July/001993.html. However, neither example contained an id or idRef attribute, so I think id/idRef is not essential for this use case. Freek
W dniu 2012-07-18 12:45, Freek Dijkstra pisze:
On 12-07-2012 17:23, Aaron Brown wrote:
I don't have a strong opinion on using id/idRef, as the method, but the idea is based around inheritance. As an example, you have port P defined in topology T. When referencing the port in topology S, I might want to override some of its properties (e.g. include our name for its Port). So you are saying that the difference between id and idRef is that an object referenced by an id inherits some of the properties (such as Location) from the parent object, while an object referenced by an idRef does not inherit there properties?
I do like this concept.
But does NML need this? To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful. Roman
Another example might be the example I sent to the NSI list where I override the VLANs of the PortGroup so that the VLAN is chosen from a subset of the VLANs available. You mean the example in http://www.ogf.org/pipermail/nsi-wg/2012-July/001984.html? I like this use case, and I based my proposal to the NSI-WG on your ideas: http://www.ogf.org/pipermail/nsi-wg/2012-July/001993.html. However, neither example contained an id or idRef attribute, so I think id/idRef is not essential for this use case.
Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 18-07-2012 15:51, Roman Łapacz wrote:
To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful.
So you want to use idRef ONLY for pointers to another document, or also pointers within the same document? Again, why is it more useful than the use of id for X in TS2? In other words, in the following exactly, exactly what information is missing (and hence, what information would like to add to RDF that is now missing because RDF is missing the idRef)? <nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b" /> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a" /> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link> Sorry to drag this on, but I think that the standard should not only say it is useful, but also why it is useful, and how an implementation should behave differently upon seeing idRef instead of id. (I presume there is a difference in behaviour, otherwise they are the same thing and one can be removed.) Freek
On Jul 18, 2012, at 10:04 AM, Freek Dijkstra wrote:
On 18-07-2012 15:51, Roman Łapacz wrote:
To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful.
So you want to use idRef ONLY for pointers to another document, or also pointers within the same document?
Again, why is it more useful than the use of id for X in TS2?
In other words, in the following exactly, exactly what information is missing (and hence, what information would like to add to RDF that is now missing because RDF is missing the idRef)?
<nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b" /> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a" /> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link>
Sorry to drag this on, but I think that the standard should not only say it is useful, but also why it is useful, and how an implementation should behave differently upon seeing idRef instead of id. (I presume there is a difference in behaviour, otherwise they are the same thing and one can be removed.)
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes". e.g. in your example above. Let's say I'm parsing the BidirectionalLink element. Did the Link elements get defined inline, or do I need to look up their definitions elsewhere (possibly in the same document, possibly in some other document)? What if they're partially defined (e.g. the name and possibly other attributes are included, but not bandwidth)? Does the bandwidth attribute that I'm looking for not exist, or should I try to find it in a definition elsewhere? Cheers, Aaron
Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
On 18-07-2012 16:11, Aaron Brown wrote:
To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful.
So you want to use idRef ONLY for pointers to another document, or also pointers within the same document?
[...]
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes".
So how to put this info into RDF? Remember, there is no id/idRef in RDF. I previously proposed something along the lines of:
urn:ogf:network:example.net:2012:somepointer nml:isauthoritative "False"
but that got rejected, since "authority" was not the correct wording. Could either of you come up with a better proposal or wording? Thanks, Freek
On Jul 18, 2012, at 10:19 AM, Freek Dijkstra wrote:
On 18-07-2012 16:11, Aaron Brown wrote:
To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful.
So you want to use idRef ONLY for pointers to another document, or also pointers within the same document?
[...]
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes".
So how to put this info into RDF? Remember, there is no id/idRef in RDF.
I previously proposed something along the lines of:
urn:ogf:network:example.net:2012:somepointer nml:isauthoritative "False"
but that got rejected, since "authority" was not the correct wording. Could either of you come up with a better proposal or wording?
Instead of saying "i'm authoritative" or "i'm not authoritative". How about making inheritance a first-order relationship? e.g. <nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-a-to-b</Relation></nml:Link> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-b-to-a</Relation></nml:Link> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link> The idRef thing could get used as a shortcut if we wanted to simplify it in the XML-case. Cheers, Aaron
Thanks, Freek
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
W dniu 2012-07-18 16:43, Aaron Brown pisze:
On Jul 18, 2012, at 10:19 AM, Freek Dijkstra wrote:
On 18-07-2012 16:11, Aaron Brown wrote:
To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful.
So you want to use idRef ONLY for pointers to another document, or also pointers within the same document?
[...]
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes".
So how to put this info into RDF? Remember, there is no id/idRef in RDF.
I previously proposed something along the lines of:
urn:ogf:network:example.net:2012:somepointer nml:isauthoritative "False"
but that got rejected, since "authority" was not the correct wording. Could either of you come up with a better proposal or wording?
Instead of saying "i'm authoritative" or "i'm not authoritative". How about making inheritance a first-order relationship? e.g.
<nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-a-to-b</Relation></nml:Link> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-b-to-a</Relation></nml:Link> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link>
The idRef thing could get used as a shortcut if we wanted to simplify it in the XML-case.
Looks good to me. Roman
Cheers, Aaron
Thanks, Freek
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
Hi Aaron and Roman, Thanks for your input on id/idRef.
On 18-07-2012 16:11, Aaron Brown wrote:
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes". [...] Instead of saying "i'm authoritative" or "i'm not authoritative". How about making inheritance a first-order relationship? e.g.
<nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-a-to-b</Relation></nml:Link> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-b-to-a</Relation></nml:Link> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link>
The idRef thing could get used as a shortcut if we wanted to simplify it in the XML-case.
This seems a useful definition and concept, although I propose two changes to it. 1. I prefer Roman's name "reference" over my "non-authoritative" or Aaron's "inherits". At least, I think that word is the best match with Aaron's explanation above. 2. One of RDFs limitations rose its ugly head with the above syntax, since it's not possible to add an attribute (like "inherits" here) to a relation in RDF. But since the "inherits" really applies to the Link, not to the relation, this can be remedied by the following syntax: <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:property name="isReference">true</nml:name> </nml:Link> which is equivalent to: <nml:Link idRef="urn:ogf:network:example.net:2012:mylink-a-to-b" /> If this seems OK to both of you, I'll make a formal proposal. Note that the "isReference" in this proposal is only use to signal that a the object is defined _in another document_. So for references within a document, "id" should be used. E.g.: <nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b" /> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a" /> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link> Regards, Freek (PS: Maybe the isReference in nml:property should be a full URI, just as in a nml:Relation)
W dniu 2012-07-20 14:24, Freek Dijkstra pisze:
Hi Aaron and Roman,
Thanks for your input on id/idRef.
On 18-07-2012 16:11, Aaron Brown wrote:
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes". [...] Instead of saying "i'm authoritative" or "i'm not authoritative". How about making inheritance a first-order relationship? e.g.
<nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-a-to-b</Relation></nml:Link> <nml:Link><nml:Relation type="inherits">urn:ogf:network:example.net:2012:mylink-b-to-a</Relation></nml:Link> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link>
The idRef thing could get used as a shortcut if we wanted to simplify it in the XML-case. This seems a useful definition and concept, although I propose two changes to it.
1. I prefer Roman's name "reference" over my "non-authoritative" or Aaron's "inherits". At least, I think that word is the best match with Aaron's explanation above.
2. One of RDFs limitations rose its ugly head with the above syntax, since it's not possible to add an attribute (like "inherits" here) to a relation in RDF. But since the "inherits" really applies to the Link, not to the relation, this can be remedied by the following syntax:
<nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:property name="isReference">true</nml:name> </nml:Link>
which is equivalent to:
<nml:Link idRef="urn:ogf:network:example.net:2012:mylink-a-to-b" />
If this seems OK to both of you, I'll make a formal proposal.
Note that the "isReference" in this proposal is only use to signal that a the object is defined _in another document_.
Fine by me. The only small possible problem I see is that this solution makes topology document quite static (not sure it's the right word; maybe less flexible to manipulate). I can imagine that a topology storage is split (even automatically) because of some reason and then we've got more than one document. During this operation references would have to be added in the right places. Roman
So for references within a document, "id" should be used. E.g.:
<nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b" /> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a" /> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link>
Regards, Freek
(PS: Maybe the isReference in nml:property should be a full URI, just as in a nml:Relation)
On 20-07-2012 15:31, Roman Łapacz wrote:
Fine by me. The only small possible problem I see is that this solution makes topology document quite static (not sure it's the right word; maybe less flexible to manipulate). I can imagine that a topology storage is split (even automatically) because of some reason and then we've got more than one document. During this operation references would have to be added in the right places.
Good one. There actually seem two scenarios. 1. A document contains an internal reference. This may be useful for a parser which does not parse the full XML at once, so it knows it should continue. 2. A document contains an external reference. This may be useful for a parser so it knows if it does not find certain information, it can not conclude that that information is absent (it may simply be defined elsewhere). In addition, in this second scenario a parser which encounters a network object without properties and without the reference flag may raise a warning because either the flag is missing, it is missing properties, or there is a typo in the URI. My proposal only covers this second example. You are right that this requires work when a topology description is split or merged, but I think that is the case anyhow -- at least I see a need for some checks and rewrites anyway before I'm going to accept a Topology description from another domain before I add it "As is" to my database. Freek
On Jul 20, 2012, at 9:50 AM, Freek Dijkstra wrote:
On 20-07-2012 15:31, Roman Łapacz wrote:
Fine by me. The only small possible problem I see is that this solution makes topology document quite static (not sure it's the right word; maybe less flexible to manipulate). I can imagine that a topology storage is split (even automatically) because of some reason and then we've got more than one document. During this operation references would have to be added in the right places.
Good one. There actually seem two scenarios.
1. A document contains an internal reference. This may be useful for a parser which does not parse the full XML at once, so it knows it should continue.
2. A document contains an external reference. This may be useful for a parser so it knows if it does not find certain information, it can not conclude that that information is absent (it may simply be defined elsewhere).
In addition, in this second scenario a parser which encounters a network object without properties and without the reference flag may raise a warning because either the flag is missing, it is missing properties, or there is a typo in the URI.
My proposal only covers this second example. You are right that this requires work when a topology description is split or merged, but I think that is the case anyhow -- at least I see a need for some checks and rewrites anyway before I'm going to accept a Topology description from another domain before I add it "As is" to my database.
I guess I'm not sure what the purpose is in differentiating "defined in the same document" vs. "defined in a different document". From my perspective, it's either "the network element i'm describing is defined here in the element being parsed", or "the network element i'm describing is defined somewhere outside the element being parsed". Cheers, Aaron ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
W dniu 2012-07-20 16:00, Aaron Brown pisze:
On Jul 20, 2012, at 9:50 AM, Freek Dijkstra wrote:
On 20-07-2012 15:31, Roman Łapacz wrote:
Fine by me. The only small possible problem I see is that this solution makes topology document quite static (not sure it's the right word; maybe less flexible to manipulate). I can imagine that a topology storage is split (even automatically) because of some reason and then we've got more than one document. During this operation references would have to be added in the right places.
Good one. There actually seem two scenarios.
1. A document contains an internal reference. This may be useful for a parser which does not parse the full XML at once, so it knows it should continue.
2. A document contains an external reference. This may be useful for a parser so it knows if it does not find certain information, it can not conclude that that information is absent (it may simply be defined elsewhere).
In addition, in this second scenario a parser which encounters a network object without properties and without the reference flag may raise a warning because either the flag is missing, it is missing properties, or there is a typo in the URI.
My proposal only covers this second example. You are right that this requires work when a topology description is split or merged, but I think that is the case anyhow -- at least I see a need for some checks and rewrites anyway before I'm going to accept a Topology description from another domain before I add it "As is" to my database.
I guess I'm not sure what the purpose is in differentiating "defined in the same document" vs. "defined in a different document". From my perspective, it's either "the network element i'm describing is defined here in the element being parsed", or "the network element i'm describing is defined somewhere outside the element being parsed".
Do I understand correctly that for referencing just id is enough (doesn't matter whether a referenced element is in the same document or not). Only inheritance would require an extension (new Relation name or property)? Roman
Cheers, Aaron
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
On 20-07-2012 16:00, Aaron Brown wrote:
On Jul 20, 2012, at 9:50 AM, Freek Dijkstra wrote:
On 20-07-2012 15:31, Roman Łapacz wrote:
Fine by me. The only small possible problem I see is that this solution makes topology document quite static (not sure it's the right word; maybe less flexible to manipulate). I can imagine that a topology storage is split (even automatically) because of some reason and then we've got more than one document. During this operation references would have to be added in the right places.
Good one. There actually seem two scenarios.
1. A document contains an internal reference. This may be useful for a parser which does not parse the full XML at once, so it knows it should continue.
2. A document contains an external reference. This may be useful for a parser so it knows if it does not find certain information, it can not conclude that that information is absent (it may simply be defined elsewhere).
In addition, in this second scenario a parser which encounters a network object without properties and without the reference flag may raise a warning because either the flag is missing, it is missing properties, or there is a typo in the URI.
My proposal only covers this second example. You are right that this requires work when a topology description is split or merged, but I think that is the case anyhow -- at least I see a need for some checks and rewrites anyway before I'm going to accept a Topology description from another domain before I add it "As is" to my database.
I guess I'm not sure what the purpose is in differentiating "defined in the same document" vs. "defined in a different document".
In one case the parser should encounter the referred element before it's done parsing, in the other case he may not.
From my perspective, it's either "the network element i'm describing is defined here in the element being parsed", or "the network element i'm describing is defined somewhere outside the element being parsed".
More precisely: 0. "the network element i'm describing is defined here in the element being parsed" 1. "the network element i'm describing is defined somewhere outside the element being parsed, but elsewhere in this file". 2. "the network element I'm describing is defined somewhere outside the file being parsed". You're asking "why do we distinguish between 0+1 on one hand and 2 on the other hand?" Assume that my parser is finished with a file and found no property X for network object N. If I than ask it "does network element N has property X", in scenario 2, it will reply with "I don't know -- it may be defined elsewhere", while in scenarios 0+1 it will reply with "it is not defined". So the answer is: the logic is different. May I counter this with the questions "why do we distinguish between 0 on one hand and 1+2 on the other hand?" I have no objection to make the distinction, but wonder why. I presume that all of the XML file is loaded into memory, and it is trivial to see that a URI occurs elsewhere or not. (I'm aware of a method to parse XML files element-by element so that full file does not need to be loaded in memory, but I don't think this will be used for NML.) Freek
Hey Freek, On Jul 20, 2012, at 10:49 AM, Freek Dijkstra wrote:
On 20-07-2012 16:00, Aaron Brown wrote:
On Jul 20, 2012, at 9:50 AM, Freek Dijkstra wrote:
On 20-07-2012 15:31, Roman Łapacz wrote:
Fine by me. The only small possible problem I see is that this solution makes topology document quite static (not sure it's the right word; maybe less flexible to manipulate). I can imagine that a topology storage is split (even automatically) because of some reason and then we've got more than one document. During this operation references would have to be added in the right places.
Good one. There actually seem two scenarios.
1. A document contains an internal reference. This may be useful for a parser which does not parse the full XML at once, so it knows it should continue.
2. A document contains an external reference. This may be useful for a parser so it knows if it does not find certain information, it can not conclude that that information is absent (it may simply be defined elsewhere).
In addition, in this second scenario a parser which encounters a network object without properties and without the reference flag may raise a warning because either the flag is missing, it is missing properties, or there is a typo in the URI.
My proposal only covers this second example. You are right that this requires work when a topology description is split or merged, but I think that is the case anyhow -- at least I see a need for some checks and rewrites anyway before I'm going to accept a Topology description from another domain before I add it "As is" to my database.
I guess I'm not sure what the purpose is in differentiating "defined in the same document" vs. "defined in a different document".
In one case the parser should encounter the referred element before it's done parsing, in the other case he may not.
I guess the difference between how we're looking at it is that I'm looking at it from the perspective of a topology service where someone could do a lookup for the ID, and be returned the network object, not the entire (possibly huge) topology, and in that case, the parser won't encounter the referred element before it's done parsing since it's only being given a document consisting of one element. Now, if they ask for the entire topology, the element will be in the same 'document'. In that case, the service would have to do translation on the fly purely to match the semantics of the above. I guess I view the logic of "same document" vs. "different document" as not that big a difference. If the parser hits the end, and doesn't have the defined element, it needs to do a lookup for the element, or if it doesn't have any way to do the lookup, it proceeds as though that element doesn't exist. Cheers, Aaron
From my perspective, it's either "the network element i'm describing is defined here in the element being parsed", or "the network element i'm describing is defined somewhere outside the element being parsed".
More precisely: 0. "the network element i'm describing is defined here in the element being parsed" 1. "the network element i'm describing is defined somewhere outside the element being parsed, but elsewhere in this file". 2. "the network element I'm describing is defined somewhere outside the file being parsed".
You're asking "why do we distinguish between 0+1 on one hand and 2 on the other hand?"
Assume that my parser is finished with a file and found no property X for network object N. If I than ask it "does network element N has property X", in scenario 2, it will reply with "I don't know -- it may be defined elsewhere", while in scenarios 0+1 it will reply with "it is not defined". So the answer is: the logic is different.
May I counter this with the questions "why do we distinguish between 0 on one hand and 1+2 on the other hand?"
I have no objection to make the distinction, but wonder why. I presume that all of the XML file is loaded into memory, and it is trivial to see that a URI occurs elsewhere or not. (I'm aware of a method to parse XML files element-by element so that full file does not need to be loaded in memory, but I don't think this will be used for NML.)
Freek
Internet2 Fall Member Meeting Sep 30-Oct 4, 2012 - Philadelphia, PA http://events.internet2.edu/2012/fall-mm/
W dniu 2012-07-18 16:11, Aaron Brown pisze:
On Jul 18, 2012, at 10:04 AM, Freek Dijkstra wrote:
On 18-07-2012 15:51, Roman Łapacz wrote:
To me IdRef is only for referencing/reusing or chaining existing elements. That's all. Without inheritance. Simple use case: a resource X is defined in a topology storage/service TS1. X is pointed in a topology storage/service TS2 (e.g. to describe multi-domain link). Use of IdRef for X in TS2 is very useful.
So you want to use idRef ONLY for pointers to another document, or also pointers within the same document?
Again, why is it more useful than the use of id for X in TS2?
In other words, in the following exactly, exactly what information is missing (and hence, what information would like to add to RDF that is now missing because RDF is missing the idRef)?
<nml:BidirectionalLink id="urn:ogf:network:example.net:2012:mylink"> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b" /> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a" /> </nml:BidirectionalLink> <nml:Link id="urn:ogf:network:example.net:2012:mylink-a-to-b"> <nml:name>A to B</nml:name> </nml:Link> <nml:Link id="urn:ogf:network:example.net:2012:mylink-b-to-a"> <nml:name>B to A</nml:name> </nml:Link>
Sorry to drag this on, but I think that the standard should not only say it is useful, but also why it is useful, and how an implementation should behave differently upon seeing idRef instead of id. (I presume there is a difference in behaviour, otherwise they are the same thing and one can be removed.)
I think the difference is in saying "i've created a new element right here with id X" vs. "i'm referencing an element with id X that is defined elsewhere". I think this is where it dovetails with inheritence. It's basically letting people know "i'm defining 0 or more attributes about this element, but you need to go elsewhere to find the rest of the attributes".
So far I haven't thought about inheritance while using idRef (only referencing) but now I see it's interesting approach and may be useful. Free: Again, why is it more useful than the use of id for X in TS2? Presence of idRef indicates clearly that a parser has to find a definition somewhere else (in the same file or different storage, also different domain).
e.g. in your example above. Let's say I'm parsing the BidirectionalLink element. Did the Link elements get defined inline, or do I need to look up their definitions elsewhere (possibly in the same document, possibly in some other document)? What if they're partially defined (e.g. the name and possibly other attributes are included, but not bandwidth)? Does the bandwidth attribute that I'm looking for not exist, or should I try to find it in a definition elsewhere?
Right. Does an empty element with id mean that it is created in a wrong way or relevant content is somewhere else? idRef says clearly that definition is somewhere else. Roman
Cheers, Aaron
Freek
_______________________________________________ nml-wg mailing list nml-wg@ogf.org <mailto:nml-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nml-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
Roman and Aaron, If I understood correctly: Roman liked id/idRef "to make distinction between definitions and references to those definitions." Aaron does not have a strong opinion about id/idRef but likes "the idea based around inheritance." I previously proposed (artf6555) id/idRef to distinguish between authority ("id meaning 'this is my resource, I can tell you all about it' and idRef meaning 'I'm just pointing to someone else's resource') So far the good news. The bad news is a practical problem I have in translating from RDF to XML. RDF does not contain id or idRef attributes. So when I take some RDF-NML description and want to translate this to XML-NML, when exactly do I use "id" and when do I use "idRef"? This is not apparent to me, but the standard need to describe this rule in detail. So either we: 1. Add some additional info to RDF which determines when id and when idRef should be used in XML. 2. pick id or idRef in XML purely based on the syntax, but not on any semantics (e.g. an XML element without children uses idRef, an XML element with children uses id) 3. Remove idRef and just use id everywhere I prefer #3 over #2 for simplicity, but can imagine that #1 is really what we want. Roman and/or Aaron, could either of you come up with a clear proposal for #1? Freek
participants (3)
-
Aaron Brown -
Freek Dijkstra -
Roman Łapacz