Hi Freek/All; On 12/13/10 3:07 PM, Freek Dijkstra wrote:
Jason Zurawski wrote:
A better syntax proposal is indeed (note that nml:segment is replaced by nml:link, and nm:idRef is replaces by nm:id):
<nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound" cl:type="partial"> <nml:link nm:id="urn:ogf:network:example.net:segmentAB"/> </nml:relation> </nml:link>
I still think this is a little off. I would assume that 'segmentAB' belongs to someone already? If this is the case, it's defined already, so you would use an idRef (as a pointer) in the second enclosed link instead of an id. If it is not already defined, than the use of 'id' is appropriate, but brings up another issue of defining links within relations/other links. We have avoided this in the past.
Actually, it is still not quite clear to me why there is a need to distinguish between id and idRef. If two objects have with the same value for the id attribute, it is clear they refer to the same thing.
(Obviously I can imagine a few reasons to distinguish between id and idRef. For example (1) RDF has them both -with different names- for syntaxtic reasons; (2) id is used by authoritative sources, while idRef is used by non-authoratitive sources; (3) id is used when the object is defined the first time in a document, and idRef is used subsequently. Neither of these reasons is very convincing to me; perhaps you can elaborate a bit more what distinction you see and why this distinction is required.)
Typically 'id' is the definition of something, 'idRef' is used as a pointer to something previously defined. Two quick examples from NMC/perfSONAR: 1) Every data has an id field, but also a 'metadataIdRef' which points to the 'parent' metadata for that data item. 2) Every 'metadata' in perfSONAR has an id field. Chaining is performed by inserting a 'metadataIdRef' inside of an empty subject, this allows us to perform filtering operations on the metadata that is 'referenced'. Following these examples, I would claim that if some domain defines/owns an object, such as a link, they get to assign the 'id' field. If this is a GLIFesq definition I would assume this gives it a global scope. For any other use that wishes to reference this original, there needs to be a clear semantic meaning that we are not trying to define (or re-define) the original. In the case of an end to end path that is using several links that belong to others (e.g. the control plane world), I am suggesting that if you intend to reference the individual components of the entire path, it is necessary to use idRefs instead of ids. Hope this helps.
I would make the example as so (again, removing the use of the attribute namespaces since I also feel this is really confusing things):
<nml:link id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.net:segmentAB"/> </nml:relation> </nml:link>
Lastly the inclusion of the 'type=partial' is still rather foreign to me, so I omitted it. Can you explain why you need to do this?
In the above I was trying to describe the following information: "urn:ogf:network:example.net:segmentAB is a segment of the end-to-end link urn:ogf:network:example.net:pathAC, but I don't know the names of other segments of this path".
This seems typical information that the domain who provisioned urn:ogf:network:example.net:segmentAB might say.
The addition of the word "partial" was trying to emphasis that, but I agree that it can be conveyed with other means (such as the lack of a "count" attribute in the above, meaning that the list may be incomplete.)
Alright. I would vote for Aaron's proposal that I listed out in one of the first mails (no longer in this tread for some reason) to use pointer elements instead of count/type elements. I believe that respects the original hop/path idea a little closer. If the existing tooling can deal with a concept that 'follows' a path, that's a strong argument to remain with it even if the syntax changes slightly. Thanks; -jason