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/