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.