Re: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07

[Martin Bjorklund <[e-mail]>]

Hi,

Thanks for your review and comments!

All comments together are being considered by the editors and possibly will
result in a new revision.  But I have some follow up comments inline:

Joshua Bell <[e-mail]> wrote:
> Section 8.9.1 XPath Capability Description includes:
> 
>    The data model used in the XPath expression is the same as that used
>    in XPath 1.0 [2], with the same extension for root node children as
>    used by XSLT 1.0 [11] (section 3.1).  Specifically, it means that the
>    root node may have any number of element nodes as its children.
> 
> 
> It is unclear how this applies. My understanding is that in XSLT this
> wording refers to the results tree of a transform

In XLST, it applies to both input and output.  This is specified in
the last paragraph in http://www.w3.org/TR/xslt#root-node-children,
repeated here:

    When the source tree is created by parsing a well-formed XML
    document, the root node of the source tree will automatically
    satisfy the normal restrictions of having no text node children
    and exactly one element child. When the source tree is created in
    some other way, for example by using the DOM, the usual
    restrictions are relaxed for the source tree as for the result
    tree.

In NETCONF's case, the data model available from a server is a set of
data models, where (normally) each such data model has its own
top-level node, e.g.:

  <interfaces xmlns="A">...</interfaces>
  <system xmlns="B">...</system>

In the XPath filters, these nodes are refered to using:

   /interfaces/...   /system/...

So the root node has all these top-level nodes as children.
   
> On a possibly related note, the next bit which describes how the node-set
> selected by the XPath expression yields the output tree seems
> underspecified:
> 
>    The response message contains the subtrees selected by the filter
>    expression.  For each such subtree, the path from the data model root
>    node down to the subtree, including any elements or attributes
>    necessary to uniquely identify the subtree, are included in the
>    response message.
> 
> 
> It is unclear (to me) exactly what the output should be when the node-set
> results of the XPath expression contains multiple nodes. For example
> (simplified
> relative to the examples in the I-D). given the filter:
> 
>    select="/users/user[name='fred' or name='barney']
> 
> Would this yield:
> 
>            <users>
> 
>              <user>
>                <name>fred</name>
>              </user>
> 
>              <user>
>                <name>barney</name>
>              </user>
> 
> </users>
> 
> 
> or:
> 
>            <users>
>              <user>
>                <name>fred</name>
>              </user>
>            </users>
> 
> 
>            <users>
>              <user>
>                <name>barney</name>
>              </user>
>            </users>
> 
> 
> The former is strongly implied by the non-XPath-based filter logic defined
> in section 6 (i.e. the text "Specific data instances are not duplicated in
> the response in the event that the request contains multiple filter subtree
> expressions that select the same data."), but the latter is hinted at by the
> note about the "XSLT extension for root node children" called out above. In
> either case, more clarity in the normative text would be worthwhile, as well
> as an example.

It is supposed to be the former.  Note that the XPath expression
really returns just a node set.  This is just a set of nodes in the
tree, and the idea is that when these nodes are represented in XML,
the server will generate elements representing each node from the top,
and not generate duplicate elements.  So maybe we can just add the
sentence you quoted above:

  Specific data instances are not duplicated in the respone.



/martin