On 04/04/2022 17:16, Andy Bierman wrote:
On Mon, Apr 4, 2022 at 4:48 AM Jernej Tuljak
<jernej.tul...@mg-soft.si> wrote:
On 01/04/2022 15:49, Andy Bierman wrote:
On Fri, Apr 1, 2022 at 4:24 AM Kent Watsen <k...@watsen.net> wrote:
Hi Jernej,
> RFC7950, 7.14.4. says:
>
> Input parameters are encoded as child XML elements to
the rpc node's
> XML element, in the same order as they are defined
within the "input"
> statement.
>
> For the following model:
>
> module b {
> namespace "b:uri";
> prefix b;
>
> grouping params {
> container params {
> leaf x {
> type string;
> }
> }
> }
>
> rpc foo {
> input {
> uses params {
> augment params {
> leaf y {
> type string;
> }
> }
> }
> }
> }
> }
>
> If both "leaf" data nodes are instantiated (XML encoding)
as part of <rpc> for "foo", does <x> come before or after <y>
(in document order)?
Augmented-in nodes come after other nodes.
Maybe this is an implementation convention, but the RFC says they
are encoded in any order.
https://datatracker.ietf.org/doc/html/rfc7950#section-7.17.2
You are referring to this:
When a node is augmented, the augmenting child nodes are encoded as
subelements to the augmented node, in any order.
This implies interleaving of augmenting and non-augmenting child
nodes within "input" parameters for XML encoding?
There is no data node order defined except in 4 places:
- rpc or action input (just the child nodes or all descendants?)
- rpc or action output (just the child nodes or all descendants?)
- ordered by user applies to list and leaf-list entries
(not the nodes within a list, just the list entries themselves)
- list key leafs are encoded in key-stmt order, before other list
child nodes.
This is true even if the list is affected by previous 3 rules (but
this is not specified)
Additionally, there are interleaving rules for list and leaf-list entries.
The XML elements representing
list entries MAY be interleaved with elements for siblings of the
list, unless the list defines RPC or action input or output
parameters.
The XML elements
representing leaf-list entries MAY be interleaved with elements for
siblings of the leaf-list, unless the leaf-list defines RPC or action
input or output parameters.
Until augmentation comes along?
It is not clear if the phrase "in any order" (appearing about a dozen
times)
is in addition to these rules or instead of them.
I'm not convinced of your interpretation of "in any order" in text you
were originally referring to (and I later quoted). No matter how many
times I read that, the "in any order" there only becomes relevant if
there is more than one augmenting child present - to me, the intention
behind that text was to handle multiple augments targeting the same
node, not to introduce interleaving with non-augmenting children.
There should be text present in that section clarifying what that
sentence means in contexts where order matters.
What about an 'anyxml' or 'anydata' for a <config> node?
Since it is a terminal node, it could be interpreted that it is ordered,
but it is converted to regular nodes when applied to a datastore.
The way I see it, only the node representing the <config> node is an
input/output parameter. The content is an opaque blob of data. No
different to a leaf of type binary, which contains bytes of an XML document.
With such ambiguity in the RFC it would not be surprising if
implementations chose to ignore these rules entirely and just accepted
RPC payloads with arbitrary order of their content, even for the cases
where things are somewhat clear. Or hope that all other implementations
follow the same implementation convention.
Jernej
Andy
Jernej
I’ve always wished there were a way to specify where they’re
placed, for readability, but it’s too inconsequential to
raise as an issue here.
There is no canonical order defined for any schema nodes.
There is no order at all defined for top-level or augmenting
schema nodes.
> Jernej
Kent
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
