Re: [Netconf] XML element order
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Netconf] XML element order
Leif Johansson writes:
>I think this question may be related to the question I asked at the
>mic in Dublin about the uniqueness of representation of a yang
>model in xml form. A necessary (but probably not sufficient)
>requirement that since yang lists are order-preserving the
>corresponging xml representation needs to be order-preserving
>too.
>
>It is absolutely critical for yang that there is a *unique* mapping
>between yang and xml since yang uses xpath.
XML encoding should be predictable and consistent, but need for
"uniqueness" implies a level of exactness that XML is meant to be
the solution for. If you define two leafs in a container, your
program (and certainly any XPath expressions you write) should not
can which order those elements arrive in, _unless_ that order carries
some semantic information.
rpc ping {
input {
leaf size { ... }
leaf count { ... }
leaf wait { ... }
}
}
There is no semantic difference between:
<rpc>
<ping>
<size>1024</size>
<count>10</count>
<wait>5</wait>
</ping>
</rpc>
and:
<rpc>
<ping>
<count>10</count>
<size>1024</size>
<wait>5</wait>
</ping>
</rpc>
or:
<rpc><ping><count>10</count><size>1024</size><wait>5</wait>
</ping></rpc>
Order and whitespace differences only matter when they matter,
and shouldn't become CLRs any other time. The XPath expression
"ping/count" finds the count no matter the order. Assuming that
"ping/*[position() = 1]" is the count will give you fragile code.
Thanks,
Phil
_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.