Re: [j-nsp] understaning the copy-node in SLAX

[Martin T]

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

[Phil Shafer]

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

[Martin T]

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

[Phil Shafer]

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