W dniu 2012-07-11 14:34, Freek Dijkstra pisze:
On 11-07-2012 14:10, Roman Łapacz wrote:
W dniu 2012-07-10 22:27, Freek Dijkstra pisze:
<nsi:path> <!-- Two STP, each with a source and sink: a bidirectional path --> <nsi:STP> <Network>urn:ogf:network:cesnet.cz:2012:czechlight</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:nordu.net:2012:nordunet-surfnet</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</nml:PortGroup></sink> </nsi:STP> <nsi:STP> <Network>urn:ogf:network:sne.science.uva.nl:2012:lighthouse</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress</nml:PortGroup></sink> </nsi:STP> </nsi:path>
Freek, in your examples sent to the NSI group you didn't use idRef attribute for nml:GroupPort (or nml:Port). It's a small thing but I think we should be strict to use accepted structures. To me using tag values for this is not supported by NML at the moment (if we had xsd or rnc schema this would be verified easily). Hi Roman,
That's correct, but the above isn't NML. It is NSI which is referring to NML objects. Given that NSI does not use id/idRef I decided to use their syntax.
But you are right that in that case I shouldn't have used the nml namespace if it is not NML.
What do you suggest?
I would not use nml namespace if the elements don't apply NML schema. Simply, I would remove it from your examples.
I can understand the desire to make it a short piece of NML, but that would require introducing id/idRef, the hasInboundPort/hasOutboundPort relations, hence the nml:Relation construct. The original proposal used query parts in the URN, which is not part of NML (I'm not even sure if the query part is part of the URN or not -- see my mail http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html).
I like Aaron proposal to use child elements and keep URN identifiers/strings static.
A further complication was that the NSI in some case want to define a Port or subset of the PortGroup within a larger PortGroup by identifying it by its label or label subset, without actually naming the result. That would require me to introduce unnamed NML objects (NML objects without a URN identifier, that are identified by their properties). I may want to do that anyway, but felt this was a bit too much wrestling if all I wanted was a reference.
Do we really need to have such unnamed NML objects? Maybe some query syntax used by NSI would represent the groups filtered from NML topologies (clear distinction: NML gives topology data, applications parse/fetch/filter that data the way they need). Roman
But by all means rewrite the examples and propose it to NML + NSI. To me this is not NML, but you have a valid argument that if this is just syntactic sugar to define a reference, why not make the sugar look like the same.
Regards, Freek