Re: [j-nsp] understaning the copy-node in SLAX
On Mon, Feb 5, 2018 at 9:15 PM, Phil Shafer wrote: > Martin T writes: >>Thanks! And this technique is useful in case cli process expects an >>element node(for example "interface-information") to have additional >>attribute nodes(for example "junos:style="terse"")? Does it provide >>any advantages over statically specifying the attribute node? > > No, there's really no advantage. I almost didn't bother including > it in the language; it's just there for completeness. "element > name()" gives identical functionality. > >>For >>example, here I rewrote two named templates and a match template of an >>op script example from "Automating Junos Administration" book: > > Can you give a page number? > >>template handle-logical-intf($family) { >> { >>for-each (*[name() != "address-family"]) { >>copy-of .; >>} >>for-each (address-family[address-family-name=$family]) { >>copy-of .; >>} >>} >>} > > You might want: > > { > copy-of @*; > for-each ... > > ... to copy the attributes off the current node. > > Using "copy-node" here gives you a means of avoiding hardcoding > the name, but that's pretty unimportant for code like this where > the functionality is so closely tied to the name. > > If the W3C had given copy-node a target xpath or an interesting > default content template (like the identity template), then it would > be more useful. But it doesn't. > > Thanks, > Phil Phil, thanks for explaining this! The page number for this script, which I mentioned, is 391. Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] understaning the copy-node in SLAX
Martin T writes: >Thanks! And this technique is useful in case cli process expects an >element node(for example "interface-information") to have additional >attribute nodes(for example "junos:style="terse"")? Does it provide >any advantages over statically specifying the attribute node? No, there's really no advantage. I almost didn't bother including it in the language; it's just there for completeness. "element name()" gives identical functionality. >For >example, here I rewrote two named templates and a match template of an >op script example from "Automating Junos Administration" book: Can you give a page number? >template handle-logical-intf($family) { > { >for-each (*[name() != "address-family"]) { >copy-of .; >} >for-each (address-family[address-family-name=$family]) { >copy-of .; >} >} >} You might want: { copy-of @*; for-each ... ... to copy the attributes off the current node. Using "copy-node" here gives you a means of avoiding hardcoding the name, but that's pretty unimportant for code like this where the functionality is so closely tied to the name. If the W3C had given copy-node a target xpath or an interesting default content template (like the identity template), then it would be more useful. But it doesn't. Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] understaning the copy-node in SLAX
On Fri, Feb 2, 2018 at 10:05 PM, Phil Shafer wrote: > Martin T writes: >>When I run this with traceoptions enabled, then I can see that ">a="12" b="34" c="56"/>" is present in the output document. I guess >>that this inner for-each loop, based on my example, expands to this: >> >>copy-node { >>attribute "a" { >>expr 12; >>} >>attribute "b" { >>expr 34; >>} >>attribute "c" { >>expr 56; >>} >>} >> >>Now "copy-node" does its shallow copy and copies "abc" element node >>and specified three attribute nodes to result tree. Am I correct? > > copy-node create a node with the target (default .) name which you > can then populate with contents: > > https://www.w3.org/TR/1999/REC-xslt-19991116#copying > > The xsl:copy element provides an easy way of copying the current > node. Instantiating the xsl:copy element creates a copy of the > current node. The namespace nodes of the current node are > automatically copied as well, but the attributes and children > of the node are not automatically copied. The content of the > xsl:copy element is a template for the attributes and children > of the created node; the content is instantiated only for nodes > of types that can have attributes or children (i.e. root nodes > and element nodes). > > It's rather like: > > element name() { > ... > } > >>In >>addition, why does copy-node run only once despite the fact that it is >>in the for-each loop? Is it because copy-node discards all the child >>elements of its current node and thus there are no more element >>nodes(, , based on my example) to loop through? > > It's simpler than that; it's copying the current node, so there's > only one of them. The nested "for-each" hits all the current node's > attributes, so you end up with: > > % cat /tmp/foo.slax > version 1.2; > > var $results := { > { > { > "foo"; > } > } > } > > main { > for-each ($results/abc) { > copy-node { > for-each (@*) { > attribute name(.) { > expr .; > } > } > } > } > } > % slaxproc -E -g /tmp/foo.slax > > > > > Bock % > > Thanks, > Phil Thanks! And this technique is useful in case cli process expects an element node(for example "interface-information") to have additional attribute nodes(for example "junos:style="terse"")? Does it provide any advantages over statically specifying the attribute node? For example, here I rewrote two named templates and a match template of an op script example from "Automating Junos Administration" book: template handle-logical-intf($family) { { for-each (*[name() != "address-family"]) { copy-of .; } for-each (address-family[address-family-name=$family]) { copy-of .; } } } template handle-physical-intf($family) { { for-each (*[name() != "logical-interface"]) { copy-of .; } for-each (logical-interface[address-family[ address-family-name=$family]]) { call handle-logical-intf($family=$family); } } } match / { { var $con = jcs:open(); var $rpc-query = { { ; } } var $results = jcs:execute($con, $rpc-query); expr jcs:close($con); if ($family) { { for-each ($results/physical-interface[logical-interface/ address-family[address-family-name=$family]]) { call handle-physical-intf($family=$family); } } } else { copy-of $results; } } } It behaves exactly the same as the one using the copy-node statements. thanks, Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] understaning the copy-node in SLAX
Martin T writes: >When I run this with traceoptions enabled, then I can see that "a="12" b="34" c="56"/>" is present in the output document. I guess >that this inner for-each loop, based on my example, expands to this: > >copy-node { >attribute "a" { >expr 12; >} >attribute "b" { >expr 34; >} >attribute "c" { >expr 56; >} >} > >Now "copy-node" does its shallow copy and copies "abc" element node >and specified three attribute nodes to result tree. Am I correct? copy-node create a node with the target (default .) name which you can then populate with contents: https://www.w3.org/TR/1999/REC-xslt-19991116#copying The xsl:copy element provides an easy way of copying the current node. Instantiating the xsl:copy element creates a copy of the current node. The namespace nodes of the current node are automatically copied as well, but the attributes and children of the node are not automatically copied. The content of the xsl:copy element is a template for the attributes and children of the created node; the content is instantiated only for nodes of types that can have attributes or children (i.e. root nodes and element nodes). It's rather like: element name() { ... } >In >addition, why does copy-node run only once despite the fact that it is >in the for-each loop? Is it because copy-node discards all the child >elements of its current node and thus there are no more element >nodes(, , based on my example) to loop through? It's simpler than that; it's copying the current node, so there's only one of them. The nested "for-each" hits all the current node's attributes, so you end up with: % cat /tmp/foo.slax version 1.2; var $results := { { { "foo"; } } } main { for-each ($results/abc) { copy-node { for-each (@*) { attribute name(.) { expr .; } } } } } % slaxproc -E -g /tmp/foo.slax Bock % Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] understaning the copy-node in SLAX
Hi! Let's say that I have the following node-set type variable and for-each loop: var $results := { { { "foo"; "bar"; } } } for-each ($results/abc) { copy-node { for-each (@*) { attribute name(.) { expr .; } } } } When I run this with traceoptions enabled, then I can see that "" is present in the output document. I guess that this inner for-each loop, based on my example, expands to this: copy-node { attribute "a" { expr 12; } attribute "b" { expr 34; } attribute "c" { expr 56; } } Now "copy-node" does its shallow copy and copies "abc" element node and specified three attribute nodes to result tree. Am I correct? In addition, why does copy-node run only once despite the fact that it is in the for-each loop? Is it because copy-node discards all the child elements of its current node and thus there are no more element nodes(, , based on my example) to loop through? thanks, Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp